Votre collègue a tort, la façon la plus courante est et a toujours été de mettre du code dans des fichiers .cpp (ou n'importe quelle extension que vous aimez) et des déclarations dans les en-têtes.
Il est parfois utile de mettre du code dans l'en-tête, cela peut permettre une compilation plus intelligente par le compilateur. Mais en même temps, cela peut détruire vos temps de compilation car tout le code doit être traité à chaque fois qu'il est inclus par le compilateur.
Enfin, il est souvent ennuyeux d'avoir des relations d'objets circulaires (parfois souhaitées) lorsque tout le code est constitué des en-têtes.
En bout de ligne, vous aviez raison, il a tort.
EDIT: J'ai pensé à votre question. Il y a un cas où ce qu'il dit est vrai. modèles. De nombreuses bibliothèques "modernes" plus récentes, telles que boost, font un usage intensif des modèles et sont souvent "en-tête uniquement". Cependant, cela ne doit être fait que lorsque vous utilisez des modèles, car c'est la seule façon de le faire lorsque vous les utilisez.
EDIT: Certaines personnes aimeraient un peu plus de clarification, voici quelques réflexions sur les inconvénients de l'écriture de code "en-tête uniquement":
Si vous effectuez une recherche autour de vous, vous verrez beaucoup de gens essayer de trouver un moyen de réduire les temps de compilation en cas de boost. Par exemple: Comment réduire les temps de compilation avec Boost Asio , qui voit une compilation en 14 secondes d'un seul fichier 1K avec boost inclus. Les 14 ne semblent pas "exploser", mais c'est certainement beaucoup plus long que la normale et peuvent s'additionner assez rapidement. Lorsqu'il s'agit d'un grand projet. Les bibliothèques d'en-tête uniquement affectent les temps de compilation d'une manière tout à fait mesurable. Nous le tolérons simplement parce que le boost est si utile.
De plus, il y a beaucoup de choses qui ne peuvent pas être faites uniquement dans les en-têtes (même boost a des bibliothèques que vous devez lier pour certaines parties telles que les threads, le système de fichiers, etc.). Un exemple principal est que vous ne pouvez pas avoir des objets globaux simples dans les bibliothèques d'en-tête uniquement (sauf si vous avez recours à l'abomination qui est un singleton) car vous rencontrerez plusieurs erreurs de définition. REMARQUE: les variables en ligne de C ++ 17 rendront cet exemple particulier réalisable à l'avenir.
Enfin, lorsque vous utilisez boost comme exemple de code d'en-tête uniquement, un détail énorme est souvent oublié.
Boost est une bibliothèque, pas un code de niveau utilisateur. donc ça ne change pas si souvent. Dans le code utilisateur, si vous mettez tout dans les en-têtes, chaque petite modification vous obligera à recompiler le projet entier. C'est une perte de temps monumentale (et ce n'est pas le cas pour les bibliothèques qui ne changent pas de compilation en compilation). Lorsque vous divisez des éléments entre en-tête / source et mieux encore, utilisez des déclarations avancées pour réduire les inclusions, vous pouvez économiser des heures de recompilation lorsqu'elles sont ajoutées sur une journée.