QByteArray生のバイナリデータを保存するために使用しています。データを保存するには、QByteArrayの追加機能を使用します。
255よりも解釈しやすいと思うので、バイトを表すために unsigned char を使用するのが好きです-1。ただし、次のようにゼロ値のバイトを a に追加しようとするとQByteArray:
command.append( (unsigned char) 0x00));
コンパイラはcall of overloaded append(unsigned char) is ambiguous. 私が理解しているように、これはゼロがヌルポインターとして解釈される可能性があるためですが、コンパイラーが unsigned char を const char* であるかどうか疑問に思うのではなく、なぜ char として扱わないのですか? command.append(0)もちろん、コンパイラがキャストなしで不平を言うかどうかは理解できます。
どちらのオーバーロードも型変換が必要です。1 つは からunsigned charへchar、もう 1 つは からunsigned charへconst char *です。コンパイラは、どちらが優れているかを判断しようとはしません。明示的にするように指示するだけです。1 つが完全に一致する場合は、次のように使用されます。
command.append( (char) 0x00));
unsigned charとcharは 2 つの異なるが変換可能なタイプです。unsigned charとconst char *は 2 つの異なるタイプであり、この特定のケースでは変換可能です。これは、オーバーロードされた関数のどちらも引数と完全に一致しないことを意味しますが、どちらの場合も引数はパラメーターの型に変換できます。言語の観点からは、両方の関数が同じように呼び出しに適しています。したがって、あいまいさ。
unsigned charバージョンが「より良い」一致と見なされるべきだと信じているようです。しかし、言語はあなたに同意しません。
(unsigned char) 0x00この場合、有効な null ポインター定数であるという事実から曖昧さが生じることは事実です。中間変数を導入することで問題を回避できます
unsigned char c = 0x0;
command.append(c);
cあいまいさを排除するヌルポインター定数としての資格はありません。ただし、@David Rodríguez - dribeas がコメントで指摘したように、ゼロをcharの代わりにキャストするだけであいまいさを解消できますunsigned char。