Por que std :: is_pod está obsoleto em C ++ 20?

std::is_podprovavelmente será descontinuado no C ++ 20.
Qual é o motivo dessa escolha? O que devo usar no lugar de std::is_podpara saber se um tipo é realmente um POD?

c++ typetraits

— skypjack
fonte

Consulte também open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0767r1.html e US 101 em open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf

— Baum mit Augen

Por que você quer saber se um tipo é POD?

— Marc Glisse

@MarcGlisse Uma pergunta sobre mudanças no padrão ou um traço como este não significa necessariamente que eu queira usar esse recurso. Eu encontrei a nota obsoleta enquanto pesquisava no Google e estava curioso para saber por que estava obsoleta.

— skypjack

Minha pergunta foi na verdade uma resposta indireta: ela foi removida porque (aproximadamente) não há razão para perguntar se um tipo é POD.

— Marc Glisse

Eu o usaria static_assertpara garantir que ninguém toque em structs que devem ser compartilhados com o código C.

— Mirko

POD está sendo substituído por duas categorias que fornecem mais nuances. A reunião padrão c ++ em novembro de 2017 tinha o seguinte a dizer sobre isso:

Reprovando a noção de “dados simples e antigos” (POD). Ele foi substituído por duas categorias de tipos com mais nuances, “trivial” e “layout padrão”. “POD” é equivalente a “layout trivial e padrão”, mas para muitos padrões de código, uma restrição mais restrita para apenas “trivial” ou apenas “layout padrão” é apropriada; para encorajar tal precisão, a noção de “POD” foi, portanto, abandonada. O atributo da biblioteca is_pod também foi descontinuado correspondentemente.

Para tipos de dados simples, use a is_standard_layoutfunção, para tipos de dados triviais (como estruturas simples), use a is_trivialfunção.

— DJ Klomp
fonte

Então, eles adicionam remove_cvrefde um lado, que é um traço composto, enquanto do outro lado eles removem outros traços compostos? Parece loucura. :-)

— skypjack

Parece ser trivial E o layout padrão E uma cláusula envolvendo ser POD recursivamente. A cláusula recursiva é redundante? Ou seja, isso é garantido std::is_pod<T>{} == (std::is_trivial<T>{} && std::is_standard_layout<T>{})?

— Yakk - Adam Nevraumont

@skypjack: O objetivo de remover o POD é que ele não serve mais a um propósito. A composição de "trivial" e "layout padrão" realmente não significa nada em C ++, e não há razão para restringir uma interface para POD em vez de "trivial" ou "layout padrão" com base no que você está realmente fazendo com isso. Em contraste, remover "cvref" significa algo; o tipo resultante é um tipo de objeto sem qualificadores.

— Nicol Bolas

Eu, pelo menos, realmente aprecio essa mudança. Como um programador de software de sistemas, "layout padrão" era realmente o que me preocupava o tempo todo, e a exigência de PODs não tendo construtores fez com que eles não descrevessem apropriadamente meu idioma comum de "estruturas com construtores". Anteriormente, fui forçado a chamá-los de "pseudo-PODs". Fofo, mas faz certos fãs de anime parecerem engraçados quando você fala sobre ter pseudópodes em seu código.

— TED

São std::is_pod, std::is_triviae std::is_standard_layoutem tempo de compilação? Porque em algoritmos, você pode desejar um algoritmo mais rápido usando memcpy () etc, se for compatível com o layout C.

— SJHowe