std :: is_podがC ++ 20で非推奨になるのはなぜですか？

std::is_podC ++ 20ではおそらく非推奨になります。
この選択の理由は何ですか？std::is_podタイプが実際にPODであるかどうかを知る代わりに、何を使用すればよいですか？

c++ typetraits

— skypjack
ソース

参照してくださいopen-std.org/jtc1/sc22/wg21/docs/papers/2017/p0767r1.htmlと米国101 open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf

— バウムをmitAugen

タイプがPODであるかどうかを知りたいのはなぜですか？

— Marc Glisse 2018年

@MarcGlisse標準の変更やこのような特性についての質問は、必ずしもその機能を使用したいという意味ではありません。グーグル中に非推奨のメモを見つけましたが、なぜ非推奨になったのか知りたくなりました。

— skypjack 2018年

私の質問は実際には間接的な答えでした。タイプがPODであるかどうかを尋ねる理由が（おおまかに）ないため、削除されました。

— Marc Glisse 2018年

static_assertCコードと共有する必要のある構造体に誰も触れないようにするために使用します。

— ミルコ

PODは、よりニュアンスのある2つのカテゴリに置き換えられています。2017年11月のc ++標準会議では、次のように述べています。

「プレーンオールドデータ」（POD）の概念を廃止します。これは、「トリビアル」と「標準レイアウト」の2つの微妙なタイプのカテゴリに置き換えられました。「POD」は「トリビアルおよび標準レイアウト」と同等ですが、多くのコードパターンでは、「トリビアル」または「標準レイアウト」のみに限定するのが適切です。したがって、このような精度を高めるために、「POD」の概念は廃止されました。ライブラリ特性is_podもそれに応じて非推奨になりました。

単純なデータ型の場合はis_standard_layout関数を使用し、些細なデータ型（単純な構造体など）の場合はis_trivial関数を使用します。

— DJクロンプ
ソース

それで、彼らremove_cvrefは一方の側、つまり構成された特性を追加し、もう一方の側では他の構成された特性を削除しますか？それは非常識なようです。:-)

— skypjack 2018年

それは些細で標準的なレイアウトであり、再帰的にPODであることを含む条項のようです。再帰句は冗長ですか？つまり、それは保証されていstd::is_pod<T>{} == (std::is_trivial<T>{} && std::is_standard_layout<T>{})ますか？

— Yakk-AdamNevraumont18年

@skypjack：PODを削除するポイントは、PODが目的を果たさなくなったことです。「トリビアル」と「標準レイアウト」の構成は、実際にはC ++では何の意味もありません。また、実際に行っていることに基づいて「トリビアル」または「標準レイアウト」ではなく、インターフェイスをPODに制限する理由はありません。それと。対照的に、「cvref」を削除することは何かを意味します。結果の型は、修飾子のないオブジェクト型です。

— ニコルボーラス

私はこの変更に本当に感謝しています。システムソフトウェアプログラマーとして、「標準レイアウト」は私がずっと気にかけていたことであり、コンストラクターを持たないPODの要件により、PODは私の一般的な「コンストラクターを使用した構造体」イディオムを適切に記述しませんでした。以前、私はそれらを「疑似POD」と呼ぶことを余儀なくされました。かわいいですが、コードに仮足を含めることについて話すと、特定のアニメファンがあなたを面白く見せます。

— TED

ありstd::is_pod、 std::is_triviaそして std::is_standard_layoutコンパイル時？アルゴリズムでは、Cレイアウトと互換性がある場合は、memcpy（）などを使用したより高速なアルゴリズムが必要になる場合があります。

— SJHowe 2018