¿Por qué std :: is_pod está obsoleto en C ++ 20?

92

std::is_podprobablemente estará en desuso en C ++ 20.
¿Cuál es el motivo de esta elección? ¿Qué debo usar en lugar de std::is_podpara saber si un tipo es realmente un POD?

c++ typetraits skypjack
fuente
Ver también open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0767r1.html y US 101 en open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf
Baum mit Augen
3
¿Por qué quiere saber si un tipo es POD?
Marc Glisse
8
@MarcGlisse Una pregunta sobre cambios en el estándar o un rasgo como este no significa necesariamente que quiera usar esa función. Encontré la nota obsoleta mientras buscaba en Google y tenía curiosidad por saber por qué estaba obsoleta.
skypjack
Mi pregunta fue en realidad una respuesta indirecta: se eliminó porque (aproximadamente) no hay razón para preguntar si un tipo es POD.
Marc Glisse
3
Lo usaría para static_assertasegurarme de que nadie toque estructuras que deberían compartirse con el código C.
Mirko

Respuestas:

70

POD está siendo reemplazado por dos categorías que dan más matices. La reunión estándar de c ++ en noviembre de 2017 tenía esto que decir al respecto:

Depreciar la noción de "datos antiguos sin formato" (POD). Se ha reemplazado por dos categorías de tipos más matizadas, "trivial" y "diseño estándar". "POD" es equivalente a "diseño estándar y trivial", pero para muchos patrones de código, es apropiada una restricción más estrecha a solo "diseño trivial" o simplemente "diseño estándar"; Por tanto, para fomentar tal precisión, la noción de "POD" quedó en desuso. El rasgo de biblioteca is_pod también se ha desaprobado en consecuencia.

Para tipos de datos simples use la is_standard_layoutfunción, para tipos de datos triviales (como estructuras simples) use la is_trivialfunción.

DJ Klomp
fuente
4
Entonces, agregan remove_cvrefpor un lado, ¿que es un rasgo compuesto, mientras que por el otro lado eliminan otros rasgos compuestos? Parece una locura. :-)
skypjack
6
Parece ser un diseño trivial Y estándar Y una cláusula que implica ser POD recursivamente. ¿Es redundante la cláusula recursiva? Es decir, ¿está garantizado eso std::is_pod<T>{} == (std::is_trivial<T>{} && std::is_standard_layout<T>{})?
Yakk - Adam Nevraumont
3
@skypjack: El objetivo de eliminar POD es que ya no sirve para nada. La composición de "diseño estándar" y "trivial" en realidad no significa nada en C ++, y no hay ninguna razón por la que restringirías una interfaz a POD en lugar de "diseño estándar" o "trivial" en función de lo que estás haciendo. con eso. Por el contrario, eliminar "cvref" significa algo; el tipo resultante es un tipo de objeto sin calificadores.
Nicol Bolas
5
Yo, por mi parte, realmente aprecio este cambio. Como programador de software de sistemas, el "diseño estándar" era realmente lo que me importaba todo el tiempo, y el requisito de que los POD no tuvieran constructores hacía que no describieran correctamente mi lenguaje común de "estructuras con constructores". Anteriormente me vi obligado a llamar a esos "pseudo-POD". Lindo, pero hace que ciertos fanáticos del anime se vean graciosos cuando hablas de tener pseudópodos en tu código.
TED
2
Son std::is_pod, std::is_triviay std::is_standard_layoutel tiempo de compilación? Porque en los algoritmos, es posible que desee un algoritmo más rápido usando memcpy (), etc. si es compatible con el diseño C.
SJHowe