.h vs .hpp

137 views
Skip to first unread message

Enrique Nieloud

unread,
Jun 12, 2009, 8:54:43 AM6/12/09
to cp...@googlegroups.com
Hola Gente,
Pregunto ¿les parece razonable el siguiente criterio?
Usar ".h" cuando generalmente el uso de templates es limitado, y dicho
".h" tiene su contraparte ".cpp". Y usar ".hpp" cuando el código está
fuértemente basado en templates, incluye la implementación, y por ende
no posee su contraparte ".cpp".

saludos

Fernando Cacciola

unread,
Jun 24, 2009, 9:49:14 PM6/24/09
to cp...@googlegroups.com
Hola Enrique,

¿Por qué queres establecer una regla para el uso de '.h' y/o '.hpp'? ¿Qué es lo
que ganaría el proyecto o team con esto?

Personalmente no veo absolutamente ninguna ventaja en hacer eso, y sí veo algo
más que saber a la hora escribir código. En mi experiencia, los "guidelines"
sólo deben existir para aquellos casos en los que aportan mas de lo que cuestan
(y todo guideline tiene como costo que hay que documentarlo, transmitirlo,
aprenderlo y recordarlo)

Por ejemplo, algo como:

"cada clase va en su propio header y cierto naming convention para los
nombres de las clases determina directamente el nombre del header"

Es útil porque el programador que recuerda cómo se llama la clase que quiere
usar puede inferir directamente el nombre del header que lo contiene.

Otro gudeline util sería: "todos los headers son .h (o .hpp (o .hxx))"
Esto es útil porque no hay nada que pensar, es así o así.

Mi regla de oro para guidelines y coding conventions es que cuanto menos mejor.
Si no son *indiscutiblemente* útiles, mejor olvidarlas...

HTH

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com


Enrique Nieloud

unread,
Jun 24, 2009, 10:19:28 PM6/24/09
to cp...@googlegroups.com
Hola Fer,

> ¿Por qué queres establecer una regla para el uso de '.h' y/o '.hpp'? ¿Qué es lo
> que ganaría el proyecto o team con esto?

Está.

Yo pensé que había algún tipo de convención al respecto, no sé por qué
(supongo por boost) siempre sospeché que hpp es cuando el header tiene
declaraciones y definiciones, y que el .h es más al estilo c: solo
declarativo.

Con respecto al comentario de los guidelines coincido al 100%, ya de
por sí, el C++ es un lenguaje que tiene que ser escrito con cuidado,
si a esto le agregamos un montón de guidelines, se desconcentra al
programador de lo central, pero qué se yo, hay de todo, cada maestro
con su librito. Una vez me puse a leer guías de código de google
(respecto c++, desde ya), en general son guidelines que tienden a
hacer el código más legible, pero a la vez prescinden de
características fundamentales del C++, la que más me llamó la atención
fue: Jamás sobrecargar un operador! de locos.
Voy a ver si lo encuentro...

Enrique Nieloud

unread,
Jun 24, 2009, 10:21:56 PM6/24/09
to cp...@googlegroups.com
> Una vez me puse a leer guías de código de google
> (respecto c++, desde ya), en general son guidelines que tienden a
> hacer el código más legible, pero a la vez prescinden de
> características fundamentales del C++, la que más me llamó la atención
> fue: Jamás sobrecargar un operador! de locos.
> Voy a ver si lo encuentro...

Bueno, exageré un poco, pero sí, recomiendan no sobrecargar
operadores, excepto en raras circunstancias.

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Operator_Overloading

saludos

Fernando Cacciola

unread,
Jun 24, 2009, 10:50:18 PM6/24/09
to cp...@googlegroups.com
Hola Enrique,

Ese documento de google es ya un clásico :)

En comp.lang.c++.moderated (aka c.l.cpp.m) generó flor de discusión, en
particular en relación a sus, hmmm, insólitos? argumentos en contra del uso de
excepciones.

Sin entrar en detalles, llegué (o llegamos diría) a la lamentable conclusión de
que el fuerte de los "googlers" es Python y que deberían tomarse a C++ más en
serio (o seguir con Python solamente)

Pero bueno, esa es una opinión crítica basada en algo que se filtró en el public
domain y que podría no ser representativo... aunque vaya que hizo ruido!

Consejo: NO tomes en serio ese documento.

Saludos

Fernando


Reply all
Reply to author
Forward
0 new messages