質問への回答。

質問の歴史。

C++11以前、多くのstd::stringの実装は、参照カウント（Copy-on-Write）を利用してインスタンス間で文字列データを共有し、コピーに対するメモリのフットプリントを削減していました。しかし、このアプローチは、内部の参照カウントが変更された場合に並行読み取りによってイテレータや参照が無効になるというスレッドセーフティの問題を引き起こしました。C++11では、constメンバー関数が参照やイテレータを無効にしないことを求めることでこの最適化を明示的に禁止し、短い文字列のヒープ割り当てのパフォーマンスコストを軽減するための新しい最適化戦略が必要になりました。

問題。

ヒープ割り当ては、アロケータの同期オーバーヘッドやキャッシュローカリティの問題のために高コストです。JSONパーサーやネットワークプロトコルハンドラなど、数十億の小さな文字列を処理するアプリケーションでは、5-15文字のシーケンスのためにメモリを割り当てることが実行時間を支配しています。課題は、std::stringオブジェクト自体の中に小さな文字列を格納すること—通常は64ビットシステムで32バイトに制約されている—の結びつきで、ABI互換性を壊さず、標準によって要求される強力な例外安全性保証を違反しないようにすることです。

解決策。

実装は通常、ストレージバッファのために3つのメンバーのユニオンを使用します：char* ptr_（ヒープ割り当て配列）、size_t capacity_、およびchar local_buffer_[N]（埋め込まれた配列）。ディスクリミネータは、size_メンバーの最下位ビットにエンコードされていることが多く、「SSOモード」または「ヒープモード」に文字列があるかを決定します。size() < SSO_CAPACITYの場合は、文字はlocal_buffer_に格納され、local_buffer_[size()]にヌル終端子が配置され、ヒープ割り当てを完全に回避します。より大きな文字列の場合、ptr_はヒープメモリを指し、local_buffer_は容量メタデータを格納するために再利用されるか、未使用のままです。

// 概念的な実装（簡略化）
class string {
    union {
        struct {
            char* ptr;
            size_t size;
            size_t cap;
        } heap; // cap >= SSO_CAPのときアクティブ
        
        struct {
            char buffer[15]; // 15文字 + ヌル終端子
            unsigned char size; // Packed metadata, MSB indicates heap
        } sso; // size < 15のときアクティブ
    } data;
    
    bool is_sso() const { return (data.sso.size & 0x80) == 0; }
};

実生活の状況

数多くの小さなタグ（例："35=D", "150=2"）を含むFIXプロトコルメッセージを処理する高頻度取引アプリケーションを考えてみてください。最初の実装では、各タグ値を格納するためにstd::stringを使用しており、結果として毎秒何百万ものヒープ割り当てが発生し、アロケータの競合がひどく、市場データフィードのボトルネックになっていました。

**解決策A: バッファ内の生ポインタ。**元のメッセージバッファへのchar*ポインタを使用することで、割り当てオーバーヘッドがゼロとなり、最大のパフォーマンスが得られます。しかし、このアプローチは、元のバッファが再利用またはメモリ解放されるときに文字列データがまだ必要な場合に、use-after-freeバグを引き起こす危険なライフタイム管理の問題を導入します。さらに、文字列の長さを手動で追跡する必要があり、コードの複雑性とエラーの可能性が増します。

**解決策B: メモリプールを持つカスタムアロケータ。**スレッドローカルのメモリプールを実装することで、割り当て競合が減少しますが、これには重大なテンプレートの複雑さが伴うか、コードベース全体にわたって多相アロケータが必要になります。また、割り当てオーバーヘッドを完全に排除することはできず、単に複数の文字列間でコストを償却するだけです。

解決策C: std::string_viewとSSO。読み取り専用処理にstd::string_viewを利用することでコピーを回避し、格納された値に対してstd::stringの自動SSOを利用することで安全性を確保しつつ、最小限のオーバーヘッドを実現します。主な欠点は、文字列がSSOの閾値（15-22文字）を超えたときにパフォーマンスの崖が発生し、高コストのヒープ割り当てが突然発生することです。さらに、小さな文字列を移動すると、ポインタを転送するのではなくデータがコピーされ、O(1)の移動セマンティクスを期待する開発者を驚かせる可能性があります。

チームは解決策Cを選択し、パーサーをリファクタリングして一時的な参照にstd::string_viewを使用し、持続性が必要な場合はのみstd::stringを使用しました。これにより、典型的なFIXメッセージのヒープ割り当てが95%削減され、スループットが50,000から800,000メッセージ/秒に向上し、メモリ安全性も維持されました。

候補者が見落とすことが多い点

SSOを内部的に利用している短い文字列を移動するときに、ポインタ転送ではなく文字コピーが行われるのはなぜですか、またそれは移動された後のオブジェクトの状態にどのように影響しますか？

SSOモードでは、文字配列はstd::stringオブジェクト内に直接存在します（通常は内部ユニオンのメンバーとして）。ヒープ割り当て文字列とは異なり、移動コンストラクタは単にchar*ポインタを転送しソースをヌルにするだけですが、SSO文字列を移動するためには、ソースの内部バッファからデスティネーションの内部バッファに文字をコピーする必要があります。これは、ソースオブジェクトが破壊され、その内部バッファも壊れるために必要です。デスティネーションは、間もなく破壊されるソース内のメモリを指すことができません。したがって、小さな文字列を移動するとO(N)の複雑さがあり、移動されたオブジェクトは有効だが未指定の状態（空ではない）を維持し、破壊や再割り当てまで元の文字を保持します。

****std::stringは、SSOモードで動作しているときに、c_str()とdata()がヌル終端の文字配列を返すというC++11要件をどのように維持していますか、内部バッファサイズが固定されているのに？

実装は、SSOバッファが常に最大SSO容量（例えば、15文字の文字列に対して合計16バイト）より1バイト大きいことを保証します。長さN（N < SSO_CAPACITY）の文字列を格納する場合、実装はローカルバッファの位置Nにヌル終端を記録します。data()およびc_str()メソッドは、SSOモードではヒープポインタではなく、このローカルバッファの先頭へのポインタを返します。これにより、追加の割り当てなしにヌル終端が保証され、c_str()がヌル終端の文字列に対するconst char*を返すという標準の要件が満たされ、C++11以降、data()もヌル終端の配列を指すことが保証されます。

空のstd::stringのcapacity()が異なる標準ライブラリの実装（例えば15と22）で異なる可能性があるのはなぜで、異なる標準ライブラリのバージョンを混ぜることのABIへの影響は何ですか？

SSOバッファサイズは実装の詳細であり（libc++は通常64ビットシステムで22文字を使用してアラインメントを利用し、libstdc++は15を使用）、これは通常、std::stringオブジェクトレイアウト内でサイズ/容量メタデータをローカルバッファの隣にパッキングする方法に依存しています（通常は合計32バイト）。これが標準化されていないため、異なる標準ライブラリの実装でコンパイルされたバイナリを混ぜること（例えば、GCCでコンパイルされたライブラリからstd::stringをClangコンパイルされたアプリケーションに渡すこと）は、互換性のないメモリレイアウトのため未定義の動作を引き起こします。候補者はしばしばstd::stringが標準ABIを持っていると仮定しますが、これはライブラリの境界を越えて最もポータブルでないタイプの1つです。