Identify Pros and Cons while using QByteArray with Automation protocols

While working in the Automation area (Modbus, KNX, etc...) we had to deal with some issues. The most important being QByteArray trying to be too clever and applying some hidden (but documented) "String" like functionality. Its internal representation as char (which may be signed or unsigned) imposes some issues when using certain functions.

Why not go with a vector of bytes?

• QByteArray::fromHex(), QByteArray::toHex()
• QByteArray::fromBase64(), QByteArray::toBase64()
• QByteArray::number(), QByteArray::toInt(), QByteArray::toLong() etc.
• QByteArray::qCompress(), QByteArray::qUncompress()
• QByteArray::trimmed(), QByteArray::simplified()
• you name it ...
• All Qt API, in network for example, supports QByteArray and not a vector

What did we miss?

• Missing std::initializer_list constructor
• complementary to QByteArray::at(), it would be nice to have QByteArray::set(index, byte)
• a save version like QByteArray::value(index), QByteArray::setValue(index, byte)

What did we hate most?

• automatic conversation to signed char while using operator[] -> QByteRef
• lots of casting involved when working with unsigned char on the user side making the code ugly
• Passing raw pointers to many functions with default size argument (due to the usage of strlen() to get the size)