extension .inl y .hpp

[digimikeh]

Buenas estimados.

Estoy estudiando un libro de SFML, y en una de sus paginas al usar plantillas para cargar recursos menciona que cuando se trabaja con plantilla de clases es bueno renombrar la cabecera a .hpp y las definiciones de los metodos en .inl .. incluyendo dicho .inl al final del .hpp

El libro no explica claramente el por qué.
Se debe esto a alguna convencion o tiene un significado objetivo?


saludos y gracias.

[RayR]

Esas extensiones no tienen nada de especial, simplemente hay quienes las usan para hacer explícitas ciertas cosas.

Como sabrás, en C++ es común poner las declaraciones de funciones (y las "interfaces" de clases) en archivos de cabecera .h, y las implementaciones o definiciones en .cpp. Las cabeceras se incluyen con directivas #include , y los .cpp se compilan individualmente, y los archivos compilados resultantes se enlazan para formar el archivo final, por ejemplo .exe. Con las plantillas no se puede hacer eso, sino que también las definiciones se deben incluir en los archivos fuente como si se tratara de cabeceras (esto no es totalmente cierto, y en realidad es más complejo, pero es "correcto" de forma general). La opción más obvia sería poner las definiciones directamente en las cabeceras, pero normalmente es preferible hacer la separación de interfaz e implementación, aunque sea sólo por legibilidad. Otra forma de hacerlo es seguir separando el código con plantillas en cabeceras y  archivos .cpp, pero incluir los propios .cpp con directivas #include, justo como con los .h. Sin embargo, esto podría prestarse a confusiones. Un programador que reciba archivos .cpp y .h, podría suponer que los .cpp se deben compilar por separado, como es lo normal, pero dado que estamos hablando de plantillas, eso sería incorrecto. Si, en cambio, se usa otra convención, es posible evitar esas ambigüedades. En este caso, se supone que si el programador ve archivos .inl, sabe que no debe incluirlos para compilarse en el proyecto, sino simplemente usar las cabeceras que desee (las cuales a su vez se encargan de incluir las implementaciones, dado que son .hpp), y ya está.

Esto no es algo generalizado, y no todos lo usan, ni lo conocen. Al final da igual la convención que se use, siempre que todos los que vayan trabajar en un proyecto la conozcan y se apeguen a ella, así que no le veo mucho sentido a recomendar o no su uso. Es simplemente una opción.