c++ coding style
Sufijo de tipo C++_t,_type o none (3)
C ++ a veces usa el sufijo _type en las definiciones de tipo (por ejemplo, std::vector<T>::value_type ), también a veces _t (por ej. _t std::size_t ), o sin sufijo (clases normales, y también typedefs como std::string que es realmente std::basic_string<...> )
¿Hay alguna buena convención sobre cuándo usar qué nombre?
Los tipos de miembros se denominan type o something_type en la biblioteca estándar de C ++. Esto es legible y descriptivo, y la verbosidad agregada no suele ser un problema porque los usuarios normalmente no deletrean esos nombres de tipos: la mayoría de ellos se usan en firmas de funciones, luego auto se encarga de los tipos de devolución de funciones de miembros, y en C + +14 los alias de tipo _t se ocupan de los miembros de tipo estático de tipo de caracteres.
Esto nos lleva al segundo punto: los tipos autónomos y no miembros suelen denominarse something_t : size_t , int64_t , decay_t , etc. Sin duda hay un elemento de herencia de C allí, pero la convención se mantiene en la evolución continua de C ++. Presumiblemente, la concisión sigue siendo una cualidad útil aquí, ya que se espera que esos tipos se deletreen en general.
Finalmente, todo lo anterior solo se aplica a lo que podría llamar "derivación de tipo genérico": Dada X , dame algún tipo relacionado X::value_type , o dado un entero, dame la variante de 64 bits. Por lo tanto, la convención está restringida a los nombres comunes de tipo de vocabulario. Los nombres de clase de su lógica comercial real (incluyendo std::string ) presumiblemente no garantizan ese patrón de nomenclatura, y no creo que a mucha gente le gustaría tener que manipular cada nombre de tipo.
Si lo desea, las convenciones de nomenclatura _t y _type se aplican principalmente a la biblioteca estándar y a ciertos aspectos del estilo de la biblioteca estándar, pero no es necesario que las tome como una especie de mandato general.
Como señala correctamente la respuesta de @MarcoA., El sufijo _t se hereda en gran parte de C (y está reservado para POSIX).
Esto nos deja "sin sufijo" y _type .
Observe que no hay nombre de ámbito de espacio de nombres en std termine en _type * ; todos esos nombres son miembros de clases y plantillas de clases (o, en el caso de tipos relacionados con expresiones regulares, de un espacio de nombres anidado que en gran medida desempeña un papel de una clase). Creo que esa es la distinción: los tipos no usan el sufijo _type .
El sufijo _type solo se usa en miembros que denotan tipos, y además, generalmente cuando denotan un tipo algo "externo" a la clase contenedora. Compare std::vector<T>::value_type y std::vector<T>::size_type , que provienen de los parámetros T y Allocator la plantilla del vector, respectivamente, contra std::vector<T>::iterator , que es "intrínseco" a la plantilla de clase de vector.
* No del todo cierto, hay algunos de esos nombres (también señalados en un comentario de @jrok): common_type , underlying_type , is_literal_type , true_type , false_type . En los primeros tres, _type no es realmente un sufijo, es una parte real del nombre (por ejemplo, una metafunción para dar el tipo común o el tipo subyacente). Con true_type y false_type , de hecho es un sufijo (ya que true y false son palabras reservadas). Yo diría que es un tipo que representa un valor verdadero / falso en el sentido de metaprogramación basada en el tipo.
Como herencia C, la _t (que solía significar " definido por typedef ") se ha heredado (también están SUS / POSIX-reserved ).
Los tipos añadidos en C ++ y no están presentes en el lenguaje C original (por ejemplo, size_type ) no necesitan acortarse.
Tenga en cuenta que TTBOMK es más una observación en una convención establecida que una regla general.