Essere un tipo POD equivale esattamente ad essere un banale tipo di layout standard?

In C ++ 20, il concetto di POD è deprecato, presumibilmente perché è un tratto composito insignificante di essere banale e layout standard. Tuttavia, la definizione di POD nella bozza C ++ 20 non è esattamente "sia banale che standard-layout"; in realtà è:

Una classe POD è una classe che è sia una classe banale che una classe di layout standard e non ha membri di dati non statici di tipo classe non POD (o array di essa). Un tipo POD è un tipo scalare, una classe POD, una matrice di tale tipo o una versione qualificata cv di uno di questi tipi.

In altre parole, non solo un tipo POD è banale e layout standard, ma lo è anche in modo ricorsivo.

Questo requisito ricorsivo è ridondante? In altre parole, se un tipo è sia banale sia layout standard, è automaticamente anche ricorsivamente banale e layout standard? Se la risposta è "no", allora qual è un esempio di un tipo banale di layout standard che non riesce a essere POD?

In C ++ 20, il concetto di POD è deprecato, presumibilmente perché è un tratto composito insignificante di essere banale e layout standard.

Non corretto. Il termine POD è deprecato perché non conta più :

Il termine POD non ha più uno scopo nella norma, è semplicemente definito e si applicano restrizioni quando alcuni altri tipi conservano questa proprietà vestigiale.

In sostanza, un tipo che è sia layout banale che standard non acquisisce alcuna capacità al di là di ciò che l'essere banale e il layout standard forniscono da soli. La combinazione dei due non rende speciale il tipo e le due proprietà non hanno molto a che fare l'una con l'altra.

Il layout standard riguarda il layout dei suoi oggetti secondari non vuoti ben definiti (così come i suoi oggetti secondari di classe base vuoti non disturbano il layout del tipo). La Trivialità riguarda se l'oggetto ha qualche significato oltre il blocco di bit che memorizza (e se è concettualmente un oggetto valido se viene inizializzato con un blocco arbitrario di bit).

Se sto realizzando un modello che accetta un tipo Te voglio vedere se posso memcpyoggetti di quel tipo, non mi interessa il layout dei suoi membri; Voglio sapere se è TriviallyCopyable. Allo stesso modo, la correttezza di offsetofnon importa minimamente se la classe ha un costruttore di copie fornito dall'utente. Tutto ciò che importa è se il layout degli oggetti secondari dei membri avviene in un ordine chiaro e standardizzato.

Fondamentalmente, le persone si sono guardate intorno e hanno capito che non è rimasto nulla in C ++ che necessiti specificamente dell'intersezione di banalità e layout standard. Quindi non abbiamo bisogno di riservare un termine per questo. Quei pochi posti in cui lo standard afferma espressamente che un tipo sarà "POD" può semplicemente essere sostituito da "layout banale e standard", a seconda dei casi.

Questo requisito ricorsivo è ridondante?

Poiché entrambi i requisiti costituenti sono ricorsivi individualmente, anche l'intersezione dei due è ricorsiva. Quindi non è necessario dichiarare esplicitamente che tutti gli oggetti secondari sono anche POD. Questo è stato più che probabilmente solo un caso di una stranezza di copia e incolla, in cui la definizione originale diceva qualcosa come "tutti i membri di dati non statici devono essere tipi POD" e hanno semplicemente mantenuto tale affermazione così com'è.

La disposizione standard dipende dalla disposizione standard dei membri non statici:

[Class.prop]

Una classe S è una classe di layout standard se:

• non ha membri di dati non statici di tipo classe di layout non standard (o array di tali tipi) o riferimenti,

• ...

La banalità dipende anche dalla banalità dei membri non statici. Per semplicità, ho citato solo la regola per il costruttore predefinito, ma le altre funzioni dei membri speciali hanno una formulazione simile:

[Class.default.ctor]

Un costruttore predefinito è banale se non è fornito dall'utente e se:

• ...
• per tutti i membri di dati non statici della sua classe che sono di tipo classe (o matrice di essi), ciascuna di tali classi ha un banale distruttore.

Per quanto ne so, il requisito esplicito di PODness da applicare ai membri è ridondante, poiché deriva implicitamente anche dai requisiti di essere layout standard e banale.