問題タブ [null-terminated]

通常の C 文字列の場合、ヌル文字'\0'はデータの終わりを示します。

についてはどうstd::stringですか。ヌル文字が埋め込まれた文字列を使用できますか?

だから、テキストファイルを1行ずつ読み込んで、各行をchar配列に保存しようとしています。

ループ内のプリントアウトから、行数と行ごとの文字数が適切にカウントされていることがわかりますが、strncpy. データ配列を印刷しようとすると、奇妙な文字が 2 つしか表示されません。私は一度も働いたことがないstrncpyので、私の問題はヌル終了に関係していると思います。

私は現在、かなり大きな文字列を持っています。私が使用したい関数はパラメーターにC文字列のみを使用するため、C文字列(char *)に変換する必要があります。

ここでの問題は、文字列に多くの \0 が含まれているため、最終的な C 文字列が元の文字列よりもずっと小さくなったことです。これらの \0 は不可欠なので、単純に削除することはできません :(...

私はそうするためにさまざまな方法を試しましたが、最も一般的なのは次のとおりです。

残念ながら、C 文字列は常に最初の \0 より前の元の文字列の内容のみでした。

どんな助けでも大歓迎です！

バイト配列から null で終了する文字列を読み込もうとしています。関数のパラメータはエンコーディングです。

たとえば、次のエンコーディングの「foo」は次のとおりです。

すべてのバイトを配列にコピーし (ヌル ターミネータまで読み取る)、その配列を に渡しencoding.GetString()た場合、文字列が UTF-32 でエンコードされている場合、アルゴリズムは 2 番目のバイトの後に「ヌル ターミネータ」に到達するため、機能しません。 .

だから私は二重の質問があります.ヌルターミネータはエンコーディングの一部ですか? そうでない場合、文字列を1文字ずつデコードし、次のバイトでヌルターミネータをチェックするにはどうすればよいですか?

前もって感謝します

（提案も大歓迎です）

編集：

「foo」が null で終了し、utf-32 でエンコードされている場合、どちらになりますか?:

アップデート

これは、「c++ は c blues ではない」という単なる別のケースであることが判明しました。

私が欲しいもの

機能する唯一のもの

gccコンパイラで文字列をnullで終了させないようにするためにできるコンパイラオプションや何かがありますか。（n）定数配列を作成できるように

私は C と C++ が大好きですが、null で終わる文字列の選択には頭を悩ませずにはいられません。

• C より前に存在していた長さの接頭辞付き (つまり Pascal) 文字列
• 長さのプレフィックス付き文字列は、一定時間の長さの検索を可能にすることで、いくつかのアルゴリズムを高速化します。
• 長さのプレフィックス付き文字列を使用すると、バッファ オーバーラン エラーが発生しにくくなります。
• 32 ビット マシンでも、文字列が使用可能なメモリのサイズになるようにすると、長さのプレフィックス付き文字列は、null で終了する文字列よりも 3 バイトだけ広くなります。16 ビット マシンでは、これは 1 バイトです。64 ビット マシンでは、文字列の長さの制限として 4GB が合理的ですが、それをマシン ワードのサイズまで拡張したい場合でも、64 ビット マシンには通常十分なメモリがあり、余分な 7 バイトが null 引数のようになります。元の C 標準が (メモリの点で) 非常に貧弱なマシン向けに作成されたことは知っていますが、効率の議論は私をここで売り込むものではありません。
• 他のほとんどすべての言語 (つまり、Perl、Pascal、Python、Java、C# など) は、長さのプレフィックス付き文字列を使用します。これらの言語は通常、文字列操作のベンチマークで C よりも優れています。
• C++ はテンプレートを使用してこれを少し修正しましたstd::basic_stringが、null で終了する文字列を期待するプレーンな文字配列は依然として普及しています。ヒープ割り当てが必要なため、これも不完全です。
• ヌルで終了する文字列は、文字列に存在できない文字 (つまり、ヌル) を予約する必要がありますが、長さの接頭辞が付いた文字列には、埋め込まれたヌルを含めることができます。

これらのことのいくつかは C よりも最近明らかになったので、C がそれらを知らなかったのは理にかなっています。ただし、いくつかは C が登場する前に単純なものでした。明らかに優れた長さの接頭辞ではなく、ヌルで終了する文字列が選択されたのはなぜですか?

編集: 上記の効率化ポイントについて、いくつかの事実を尋ねた(そして、私が既に提供したものを好まなかった) ため、それらはいくつかのことに由来します:

• null で終了する文字列を使用した連結には、O(n + m) 時間の計算量が必要です。多くの場合、長さのプレフィックスには O(m) しか必要ありません。
• null で終了する文字列を使用した長さには、O(n) 時間の計算量が必要です。長さのプレフィックスは O(1) です。
• 長さと連結は、最も一般的な文字列操作です。null で終了する文字列の方が効率的である場合がいくつかありますが、その頻度ははるかに低くなります。

以下の回答から、null で終了する文字列の方が効率的である場合がいくつかあります。

• 文字列の先頭を切り取り、それを何らかのメソッドに渡す必要がある場合。長さの接頭辞はおそらく整列規則に従う必要があるため、元の文字列を破棄することが許可されていても、長さの接頭辞を使用して一定の時間でこれを行うことはできません。
• 文字列を 1 文字ずつループしているだけの場合、CPU レジスタを保存できる場合があります。これは、文字列を動的に割り当てていない場合にのみ機能することに注意してください (文字列を解放する必要があるため、保存した CPU レジスタを使用して、もともと malloc と友人から取得したポインターを保持する必要があります)。

上記のいずれも、長さと連結ほど一般的ではありません。

以下の回答には、もう1つ主張されています。

• 弦の端を切り落とす必要があります

しかし、これは正しくありません。null で終了し、プレフィックス付きの長さの文字列の時間は同じです。(null で終了する文字列は、新しい末尾にしたい場所に null を貼り付けるだけで、長さプレフィックスはプレフィックスから減算するだけです。)

配列がnull で終了している場合、これは非常に簡単です。

ただし、次のように、 null で終了しない unsigned char 配列をコピーする最も適切な方法は何だろうか。

にstd::string。

unsigned char 配列を反復せずにそれを行う方法はありますか?

皆さん、ありがとうございました。

Delphi XEでは、クリップボードからCF_UNICODETEXTデータをキャプチャしています。結果は、2つのヌルバイトで終了するストリームです。クリップボードにコピーされた実際の文字列を取得するには、nullを取り除く必要があります。

この似たような質問には、TMemoryStreamからDelphiのUnicode文字列に変換するための優れた方法が含まれています。

ただし、私の場合、これにより、末尾のnullを含む文字列が生成されます。サイズを制限することでそれを修正できます：

...しかし、これは醜い、「特別な場合」に感じます。これをコード化するためのよりクリーンな方法があるのではないかと思います。そうすれば、後でコードを見る人（私！）がすぐに「なぜ末尾の文字がストリームから削除されるのですか？」

編集：質問を先取りする1つの方法は、コメントを追加することです。しかし、それ以外は？

null を含む C (Windows) の文字列をコピーしたいと考えています。NULL 文字が無意味になるように、バッファー長を渡す関数が必要です。StringCbCopy 関数を見つけましたが、それでも最初の NULL 文字で停止します。

Herb Sutter は、2008 年の彼のサイトへの投稿で、次のように述べています。

C++0x でこれをさらに強化し、null 終了を要求し、同時実行性に関連する理由からコピー オン ライトの実装を禁止するという積極的な提案があります。ここに論文があります：http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2534.html。この論文の提案の 1 つまたは両方が採用される可能性が高いと思いますが、次の 1 回か 2 回の会議でわかります。

C++11 が std::string の内容が連続して格納されることを保証するようになったことは知っていますが、最終ドラフトで上記を採用しましたか?

のようなものを使用しても安全&str[0]ですか？