Message hors sujet, mais il fallait que je réponde à ça :

Citation Envoyé par air-dex Voir le message
Quand on ne veut pas que ce soit public on dit que c'est private. Jusqu'au jour où il y a un bout de code qui te serait bien utile et que tu ne peux pas utiliser car il est en private et non en protected. Du coup t'es obligé de faire du pompage de code pour que tu puisses l'utiliser tout en maudissant ce de développeur qui n'a pas compris l'intérêt du protected. À partir de ce moment là tu sais qu'en général il vaut mieux utiliser protected plutôt que private quand tu ne veux pas faire de public.
L'intérêt d'une fonction membre private par rapport à une fonction membre protected, c'est que, quand tu supprimes la fonction, la renommes ou changes la liste de ses paramètres, tu as seulement besoin de mettre à jour le code de la classe courante, sans modifier celui des classes dérivées.
Dans le doute, il est préférable de laisser une fonction en visibilité private, puis de changer plus tard sa visibilité en protected si on se rend compte qu'il est pertinent de l'appeler dans une classe dérivée, voire en public s'il est pertinent de l'appeler ailleurs.
Le développeur que tu as maudit avait peut-être très bien compris l'intérêt du protected.

Citation Envoyé par air-dex Voir le message
Un autre exemple qui me vient à l'esprit est le const de C++. [...] La fois suivante tu t'abstiens d'en mettre si ça peut marcher sans.
En général, c'est une mauvaise démarche. Il vaut mieux persévérer et apprendre à utiliser correctement const.
L'avantage de const, c'est de documenter de manière standard et concises qu'une variable n'est pas modifiée, avec en prime une vérification de la part du compilateur.
Le seul cas où il peut être justifié de renoncer à const malgré ses avantages, c'est quand on utilise une bibliothèque pourrie dans laquelle il manque beaucoup de const, à cause du manque d'expertise en C++ de ses concepteurs.