Improvements on Headers (.h to .hpp) [Refactoring]

[ropinho]

.hpp vs .h headers

Using headers in *.hpp format and including class definitions and implementations in the same files makes the inclusion of the headers more straightforward and reliable.

*.hpp files also provides a simplier installation process.

Projects make purely in C++ should use hpp files to includes.

Remember, C is not C ++ and it can be very dangerous to mix and match.

I suggest a refactoring on the header files format, merging the implementations which is separate of the definitions in the same files.

---

Google Translate to Franchise:

L'utilisation d'en-têtes au format * .hpp et l'inclusion de définitions de classe et d'implémentations dans les mêmes fichiers rendent l'inclusion des en-têtes plus simple et fiable.

Les fichiers * .hpp fournissent également un processus d'installation plus simple.

Les projets purement en C ++ doivent utiliser des fichiers hpp à includes.

Rappelez-vous que C n'est pas C ++ et qu'il peut être très dangereux de mélanger et d'associer.

Je suggère un refactoring sur le format des fichiers d'en-tête, fusionnant les implémentations qui sont séparées des définitions dans les mêmes fichiers.

[nojhan]

I'm not sure to get this idea correctly, because AFAIK, the headers with templates already embed the code. The only few exceptions are for utility classes that can be pre-compiled (see the eoutil lib).

Moreover, a classical organization of the code would be to put forward declarations of templates in .h headers, apart from actual template code in .hpp files, with hpp being included in headers.
That way, it is easier to read the API, not being bothered by the details of the code. The drawback is that there would be twice as much files, in a project with already too much files everywhere.

If having a more readable organization for the end user is your concern, I would suggest working on removing prefixes in favour of namespaces, add subdirectories for high-level modules and move each class to a single file.