私は最近のインタビューで C++ 構造体フィールドのアライメントについて尋ねられ、C と C++ は構造体パッキングで同じ戦略に従うと理論付けました。
しかし、それは間違った仮定でした。インタビュアーは、一般的に C と C++ は異なる方法で構造体をパッキングしており、その逆を期待すべきではないと述べました。私見それは奇妙な声明です。pack "C"バイリンガル C/C++ ヘッダー ファイルで使用するための C++ の構造体の修飾子はありません。
したがって、実際には、C++ で構造体を作成して C ライブラリに渡すことができないことを意味する可能性があります。一般に、そのフィールドは異なる方法で整列され、異なるオフセットを持つためです。しかし、実際には、ほとんどのプログラマーは、C POD構造体へのポインターを、いくつかのヘルパー メソッドを使用してこの構造体の周りの C++ ラッパーへの参照に変換する時点まで、この相互運用性に真剣に依存しています。この件について明確にしていただけますか？
これは明らかに間違っていました (インタビュアー側で)。ネットワーク API など、構造体を扱う低レベルAPIを扱った人なら誰でも、構造体のパッキングが C と C++ で同じであることは明らかです。これらはすべて「C」構造体を受け入れる C 関数ですが、C++ コードから 1 日に何百万回も安全に呼び出されます。
この質問をしたあなたはラッキーだったはずです。そこで働くべきではないことを明確にしています。
C++ が開発されたとき、開発者は、C プログラマーが、C++ 開発者が保証したくないいくつかのことに依存していることに気付きましたが、それらを保証しないということは、有効な C++ コードでもある多くの C コードが、使用すると壊れてしまうことを意味します。 C++ コードとして。望ましくない。
それが、彼らが「POD」構造を発明した理由です。C++ 機能をまったく使用しない構造体は、C++ プログラムで C プログラムとまったく同じように動作します (実装定義の動作が変更される可能性があるという事実は別として、C コンパイラとC++ コンパイラは明らかに同じ実装ではありませんが、C++ コンパイラはおそらく C コンパイラから実装定義をコピーするだけです)。
有効な C++ 構造体でもある単純な C 構造体 (たとえば、"class" という名前のメンバーがない) を使用し、左中括弧の直後に "public:" を追加すると、そのレイアウト、メンバーの順序、整列など、すべて変更できます。すべての構造体メンバーはデフォルトで public ですが、実際には何も変わっていません。ただし、"public:" のため、もはや POD ではありません。