4

POD (c++11、自明 + 標準レイアウト) の要点は、型が C と互換性があることを確認することだと思いました。

次のコードがあるとします。

// that one is a standard layout, and trivial which makes it a c++11 POD
struct Bar
{
public:
  int x;
public:
  int y;
};

AFAIU、コンパイラは x と y を並べ替える可能性があります。それは C との互換性を壊しませんか?

c++11 での 98/03 POD 定義の緩和が良い考えであると考えられるのはなぜですか?

4

3 に答える 3

4

AFAIU、コンパイラは x と y を並べ替える可能性があります。それは C との互換性を壊しませんか?

C++03 では可能です。C++11 ではできません。C++11 の標準レイアウト規則では、すべてのメンバーが同じアクセス制御を持つことだけが必要です。同じアクセス制御領域で宣言する必要はありません。

c++11 での 98/03 POD 定義の緩和が良い考えであると考えられるのはなぜですか?

あなたは物事を誤解していると思います。C++11 の規則では、より多くの型を標準レイアウトにすることができます (したがって、C 型とのレイアウト互換性がある可能性があります)。したがって、ルールを緩和することによる実際のマイナス面はありません。

于 2012-09-14T01:49:13.370 に答える
3

POD (c++11、自明 + 標準レイアウト) の要点は、型が C と互換性があることを確認することだと思いました。

それだけではありませんが、POD の特性の 1 つです。

// that one is a standard layout, and trivial which makes it a c++11 POD

正しい。

AFAIU、コンパイラは x と y を並べ替える可能性があります。それは C との互換性を壊しませんか?

これは、コンパイラが C との互換性を維持することを意味します。C との互換性を維持しても、C との互換性が損なわれることはありません。

c++11 での 98/03 POD 定義の緩和が良い考えであると考えられるのはなぜですか?

何も壊さないから。

于 2012-09-13T23:07:26.680 に答える
-1

publicPOD のポイントは、型が C と互換性があることを確認することだけではありません。C にはアクセス指定子がないため、アクセス指定子 ( 、privateなど)を持つ型は定義上 C と互換性がないことに注意してください。POD タイプの主な特性は、memcpy で処理できることです。

C++ 型に複数のアクセス指定子があると、コンパイラは指定されていない方法で型をレイアウトできますが、これはしばらくの間当てはまりました (C++11 では新しいことではありません)。

C++03 9.2/12 から

access-specifier を介在させずに宣言された (非共用体) クラスの非静的データ メンバーは、後のメンバーがクラス オブジェクト内でより高いアドレスを持つように割り当てられます。アクセス指定子で区切られた非静的データ メンバの割り当て順序は規定されていません (11.1)。

ただし、それは型を非 POD にするわけではありません。C で移植可能に表現できる型ではなく、POD である可能性があります。

于 2012-09-13T23:31:00.040 に答える