問題タブ [standard-layout]

このFAQはアグリゲートと POD に関するもので、次の内容をカバーしています。

• 集合体とは？
• POD (Plain Old Data)とは何ですか?
• それらはどのように関連していますか？
• どのように、そしてなぜ彼らは特別なのですか?
• C++11 の変更点は?

C ++ 11の新しいリラックスしたPOD定義を調べています（セクション9.7）

標準レイアウトクラスは、次のようなクラスです。

• タイプnon-standard-layoutクラス（またはそのようなタイプの配列）または参照の非静的データメンバーはありません。
• 仮想関数（10.3）および仮想基本クラス（10.1）がなく、
• すべての非静的データメンバーに対して同じアクセス制御（条項11）があり、
• 非標準レイアウトの基本クラスはありません。
• 最も派生したクラスに非静的データメンバーがなく、非静的データメンバーを持つ基本クラスが多くても1つないか、非静的データメンバーを持つ基本クラスがない。
• 最初の非静的データメンバーと同じタイプの基本クラスはありません。

私は私を驚かせたビットを強調しました。

さまざまなアクセス制御を持つデータメンバーを許容した場合、何が問題になりますか？

最初のデータメンバーが基本クラスでもあった場合、何が問題になりますか？すなわち

私はそれが奇妙な構造であることを認めます、しかしなぜ禁止されるべきBadであるが禁止されるべきではないのGoodですか？

最後に、複数の構成クラスにデータメンバーがある場合、何が問題になりますか？

C++11 標準では、バイトごとのコピーが POD 型に対して常に有効であることが保証されています。しかし、特定の自明な型についてはどうでしょうか。

次に例を示します。

この構造体をバイト単位でコピーした場合、技術的には POD ではありませんが、適切にコピーされることが保証されますか? オブジェクトをバイトコピーしてはいけないという線引きはいつですか?

C ++ 11、§9/ 7：

標準レイアウトクラスは、次のようなクラスです。

• タイプnon-standard-layoutクラス（またはそのようなタイプの配列）または参照の非静的データメンバーはありません。
• 仮想関数も仮想基本クラスもありません。
• すべての非静的データメンバーに対して同じアクセス制御があり、
• 非標準レイアウトの基本クラスはありません。
• 最も派生したクラスに非静的データメンバーがなく、非静的データメンバーを持つ基本クラスが多くても1つないか、非静的データメンバーを持つ基本クラスがない。
• 最初の非静的データメンバーと同じタイプの基本クラスはありません。

では、標準レイアウトのクラスをコピーできないようにする方法はありますか？はいの場合、どのように？

boost :: noncopyableからプライベートに継承すると、コピーコンストラクターがプライベートになります（したがって、標準のレイアウトではないため）。boost :: noncopyableの実装は次のようになります：

プライベートセクションのため、標準のレイアウトクラスではありません。また、プライベート継承が標準のレイアウトルールに違反するかどうかも確認します。

出力は次のとおりです。

上記の例は、からプライベートに継承boost::noncopyableすると、クラスが標準レイアウトに準拠しないように変更されることを示しています。これがg++のバグ（私はg ++ 4.6.1を使用しています）なのか、それとも標準に違反しているのかわかりません。

I am wrapping a simple C++ inheritance hierarchy into "object-oriented" C. I'm trying to figure out if there any gotchas in treating the pointers to C++ objects as pointers to opaque C structs. In particular, under what circumstances would the derived-to-base conversion cause problems?

The classes themselves are relatively complex, but the hierarchy is shallow and uses single-inheritance only:

I am planning on exposing this to C clients via the following, fairly standard object-oriented C:

The C clients only pass around pointers to the underlying C++ objects and can only manipulate them via function calls. So the client can finally do something like:

and have the virtual call to FirstDerived::someOperation() succeed as expected.

These classes are not standard-layout but do not use multiple or virtual inheritance. Is this guaranteed to work?

Note that I have control over all the code (C++ and the C wrapper), if that matters.

C++ POD、Trivial、Standard Layout クラスに関するすばらしい記事を読んで いましたが、標準レイアウトについて明確に理解していないプロパティの 1 つは次のとおりです。

したがって、以下は基本クラスと同じ最初のメンバーを持つため、標準レイアウトにはなりません。

しかし、パフォーマンスとプロパティの観点から、上記の構造体はどのように異なるのですか

これは、この上のものの修正です。

重複の可能性:
C++ の非 POD 構造で offsetof を使用できないのはなぜですか?

私は2つのクラスを持っています:

C++11 標準レイアウトの制限を正しく解釈すると、B と A の両方に非静的データ メンバーがあるため、B は標準レイアウトではありません。B のようなコンストラクトを HDF5 と組み合わせて使用​​したいと考えています。これには、(私の知る限り) 標準レイアウト オブジェクトに制限されているoffsetofマクロの使用が必要です。私の質問は、次のような式で何がうまくいかないかということです

gcc-4.6 では問題なく動作しますが、同様の状況で予期しない動作に遭遇した人はいますか? もしそうなら、どれとどのコンパイラを使っていますか? 最悪のシナリオとは？

よろしくクラース

A piece of code is worth a thousands words.

g ++4.7とlibstdc++を使用すると、が得られstd::is_standard_layout<A>::value == trueます。
しかし、他のコンパイラや標準ライブラリはどうなりますか？
（少なくとも確実に）STLコンテナが標準レイアウトを破らないという保証はありますか？

バックグラウンド：

これにより、の使用static_cast<B &>(a).bar()も可能になりますA a;。（これが良いデザインだと言っているのではありません！）。

C++ 標準によると、次のようになります。

標準レイアウト クラスは、次のようなクラスです。

— 非標準レイアウト クラス (またはそのような型の配列) 型または参照型の非静的データ メンバーはありません。

参照メンバーを持つクラスが標準レイアウト クラスの定義に含まれるのを妨げている参照のプロパティはどれですか?