0

(2003) 標準の構造体の定義によると、それはクラスの特殊なケースであり、メンバー、関数、および基本クラスに対して異なる既定のアクセス修飾子があります。また、構造体の要件を POD 構造体に定義することも続けます。

C++ 2003 標準、ISO 14882 セクション 9.0.4:

構造体は、class-key 構造体で定義されたクラスです。そのメンバーと基本クラス (第 10 節) はデフォルトで公開されます (第 11 節)。ユニオンは、クラス キー ユニオンで定義されたクラスです。そのメンバーはデフォルトでパブリックであり、一度に 1 つのデータ メンバーのみを保持します (9.5)。[注: クラス型の集合体は 8.5.1 で説明されています。] POD 構造体は、非 POD 構造体、非 POD 共用体 (またはそのような型の配列)、または参照型の非静的データ メンバーを持たず、ユーザー定義のコピー代入演算子を持たない集約クラスです。ユーザー定義のデストラクタはありません。同様に、POD 共用体は、非 POD 構造体型、非 POD 共用体 (またはそのような型の配列) 型、または参照型の非静的データ メンバーを持たず、ユーザー定義のコピー代入演算子を持たない集合共用体です。ユーザー定義のデストラクタ。

この定義では、POD 以外の構造体とクラスを区別する唯一の要素は、既定のアクセス修飾子です。

非POD構造体を持つ目的として私が想像できるものは次のとおりです。

  • それらは下位互換性のために維持する必要があるレガシー機能です
  • タイピングpublic:は難しいです。

非 POD 構造体を使用すると、他のシステムによって POD であると想定される場合 (たとえば、C に渡されて戻ってくる場合) に問題が生じる可能性があります。たとえば、この人物は、POD であると想定されていた構造体が別の開発者によって更新され、POD ではなくなったときに問題に遭遇しました。デフォルトでは、POD 性はコンパイラによって静的にアサートされないため、POD 構造体のみを使用できるコンテキストでその構造体が使用されると、アプリケーションは実行時にクラッシュします。さらに悪いことに、POD を必要とする特定の状況では非 POD 構造体が機能し、他の状況では失敗し、エラーやクラッシュにつながる可能性があります (これが可能かどうかはわかりません)。追跡します。

非 POD 構造体を使用すると、奇妙で​​壊れた動作の領域につながる可能性がある状況があるので、非 POD 構造体の使用は何ですか? コンパイル時に (C++11 の std::is_pod または同等の Boost を介して) 構造体が POD 性を静的にチェックされないのはなぜですか?

4

2 に答える 2

4

これは無意味な歴史的事故だと思います。率直に言って、このclassキーワードは C++ にまったく追加されるべきではありませんでした。しかたがない！

a が POD である必要がある場合、しばしば煩わしいstructものになります。何か POD から始めて、できるという理由だけでそれを「構造体」と呼び、後で多くの場所でそれを変更しなければならなくなることがよくあります。非PODにすることにしました。

GCC は (少なくとも最近まで) 何かをある場所でクラスとして宣言し、別の場所では構造体として (フォワード) 宣言したかどうか、またはその逆かどうかを気にしなかったことに注意してください。Clang はこの種のことについて不平を言っています (既存のコードを「壊す」ことはありますが、Clang にはあらゆる権利があるため)。

于 2012-02-24T01:56:14.770 に答える
0

「POD 性は、デフォルトではコンパイラによって静的にアサートされません」

おー？

#include <iostream>         // std::cout, std::endl
#include <type_traits>      // std::is_pod
#include <string>           // std::string, std::to_string
using namespace std;

struct A
{
    int x;
};

struct B
{
    string s;
};

int main()
{
    static bool const a = is_pod<A>::value;
    static_assert( a, "Ah..." );
    static_assert( !is_pod<B>::value, "Bah!" );
}

上記のstructように非 POD が許可される理由B、つまり言語がこのように設計されている理由は、おそらく Bjarne Stroustrup の著書「C++ の設計と進化」に記載されています。そうでない場合は、おそらく Bjarne 自身だけが知っています。この C++ の一般性はstruct最初から存在しているためです。

于 2012-02-24T02:05:16.323 に答える