Préparez vos questions sur l’héritage des constructeurs en C++ : ordre de construction, liste d’initialisation et pièges d’entretien. L’essentiel ici.
Most candidates who blank on C++ constructor inheritance questions aren't missing the knowledge — they're missing the sequence. They know vaguely that base constructors run first, that the initializer list is involved somehow, and that there's a `using` keyword in modern C++. But when the interviewer says "walk me through how constructors work in a derived class," the vagueness collapses under pressure. This guide on c++ constructor inheritance interview preparation gives you the memorisable answer first, then the construction order, then the traps interviewers reach for once you've cleared the opening.
The goal is a script you can actually say out loud — not a textbook summary you'd have to reconstruct on the fly.
Dites d’abord la réponse : les constructeurs ne sont pas hérités
La réponse de 20 secondes que vous pouvez dire à voix haute
Voici la réponse qu’un bon candidat donne avant même que l’intervieweur ait fini d’écrire au tableau blanc :
"Les constructeurs ne sont pas hérités en C++. Quand vous créez un objet dérivé, le constructeur de la classe dérivée appelle explicitement le constructeur de la classe de base dans sa liste d’initialisation. La classe de base est construite en premier, avant l’exécution du corps du constructeur dérivé. Si vous ne précisez pas d’appel au constructeur de base, le compilateur essaie d’appeler le constructeur par défaut de la base — et s’il n’existe pas, le code ne compile pas."
C’est tout. Dites cela, et vous avez répondu à la question centrale. Tout le reste — le fonctionnement de la liste d’initialisation, l’ordre de construction, la syntaxe moderne `using` — n’est qu’un approfondissement. Mais les intervieweurs veulent surtout savoir si vous savez que les constructeurs ne sont pas hérités et que la base est construite via un appel explicite dans la liste d’initialisation. Ces deux points constituent toute la réponse.
Ce que cela donne en pratique
Au tableau, c’est un schéma de 30 secondes. L’intervieweur voit que vous savez où se trouve l’appel au constructeur de base (dans la liste d’initialisation, pas dans le corps) et que vous passez les arguments explicitement. D’après cppreference.com, les constructeurs ne sont pas hérités par défaut — chaque classe est responsable de définir ses propres constructeurs, et la classe dérivée doit invoquer explicitement le constructeur de base approprié. C’est la règle fondatrice. Tout le reste en découle.
Appelez le constructeur de base dans la liste d’initialisation, pas dans le corps
Pourquoi la liste d’initialisation est le vrai mécanisme
La liste d’initialisation d’un constructeur C++ n’est pas un choix stylistique : c’est le mécanisme réel par lequel les sous-objets de base et les variables membres sont construits. Au moment où le corps du constructeur ouvre sa première `{`, le sous-objet de base doit déjà être entièrement construit. Ce n’est pas une convention ; c’est ainsi que le langage est défini.
Si vous essayez d’« appeler » le constructeur de base dans le corps, vous ne construisez rien — la base a déjà été construite (avec son constructeur par défaut, s’il existe) avant l’exécution du corps. Ce que vous faites dans le corps est soit une opération sans effet, soit une affectation, selon l’objet concerné. Pour l’initialisation d’une classe de base, il n’existe pas d’équivalent à une affectation. La liste d’initialisation du constructeur C++ est le seul moment où cette construction se produit.
Ce que cela donne en pratique
La version annotée rend l’ordre des étapes concret : `: Base(x)` s’exécute d’abord, le sous-objet de base entre en existence, puis le corps `{}` s’exécute. Tenter d’appeler `Base(x)` dans le corps construit un temporaire sans nom, détruit immédiatement — cela ne fait rien au vrai sous-objet `Base` intégré à `Derived`. GCC ne vous avertira pas forcément dans la mauvaise version ; il fera simplement la mauvaise chose, en silence. C’est exactement le genre de piège que les intervieweurs cherchent à repérer.
La FAQ C++ de Bjarne Stroustrup et la norme ISO C++ considèrent toutes deux l’initialisation avant le corps comme une règle fondamentale de la construction d’objet. Si un candidat l’explique correctement, il montre qu’il comprend le cycle de vie des objets — pas seulement la syntaxe.
Gérez correctement le cas sans constructeur par défaut
Pourquoi le code casse quand la base n’a pas de constructeur par défaut
Lorsque la classe de base définit un constructeur paramétré et aucun constructeur par défaut, le compilateur ne peut pas se rabattre silencieusement sur autre chose. Un appel au constructeur de base doit figurer dans la liste d’initialisation de la classe dérivée. S’il n’y est pas, le compilateur tente d’appeler un constructeur de base sans argument — et comme aucun n’existe, la compilation échoue. C’est une conséquence structurelle, pas une bizarrerie du compilateur.
L’idée clé pour un entretien : l’erreur n’est pas « vous avez oublié d’appeler le constructeur de base ». L’erreur est « le compilateur a essayé d’appeler un constructeur qui n’existe pas ». Cette distinction compte, car elle montre que vous comprenez ce que le compilateur fait réellement à votre place.
Ce que cela donne en pratique
Avec GCC, on obtient quelque chose comme :
La version corrigée est simple : transmettre l’argument requis via la liste d’initialisation du constructeur dérivé.
Les candidats qui ont réellement rencontré cette erreur dans un build la reconnaissent immédiatement. Ceux qui n’en ont lu qu’une description en inversent souvent le sens dans le message d’erreur. Si vous avez déjà vu `no matching function for call to 'Base::Base()'`, vous savez ce que cela signifie sans réfléchir.
Le suivi d’entretien : que se passe t il si le constructeur de base est private ou protected ?
Les intervieweurs enchaînent souvent la question sur l’absence de constructeur par défaut avec une question d’accès. Si le constructeur de base est private, les classes dérivées ne peuvent pas l’appeler — même dans la liste d’initialisation. La classe dérivée est alors incapable de construire le sous-objet de base, ce qui revient à dire que vous ne pouvez pas hériter de cette classe au sens habituel.
Si le constructeur de base est protected, il est accessible aux classes dérivées mais pas au code externe. C’est le schéma prévu lorsque vous voulez autoriser l’héritage tout en empêchant l’instanciation directe de la classe de base. Un candidat qui connaît cette distinction montre qu’il comprend l’accessibilité des constructeurs comme un outil de conception, et pas seulement comme une règle syntaxique.
Maîtrisez l’ordre : base d’abord, dérivée ensuite, destruction en sens inverse
Pourquoi l’ordre compte plus que la simple mémorisation
L’ordre de construction n’est pas arbitraire. Le corps de la classe dérivée et ses membres peuvent dépendre du fait que le sous-objet de base soit déjà vivant — ils peuvent appeler des méthodes de base, lire des champs de base ou s’appuyer sur des invariants établis par le constructeur de base. Si la dérivée s’exécutait en premier, ces dépendances accéderaient à de la mémoire non initialisée. Le langage impose explicitement l’ordre base-avant-dérivée pour éviter cette catégorie de bug.
La destruction suit l’ordre inverse pour la même raison : le destructeur de la dérivée s’exécute d’abord, car il peut encore utiliser le sous-objet de base. Une fois le destructeur de la dérivée terminé, le sous-objet de base est détruit. Détruire la base en premier laisserait le destructeur de la dérivée agir sur un objet mort.
Ce que cela donne en pratique
Sortie dans le terminal :
C’est l’une des choses les plus utiles à esquisser au tableau lors d’une discussion d’entretien sur les questions d’héritage en C++. La sortie rend l’ordre concret d’une manière qu’une explication orale seule ne permet pas. Les intervieweurs qui vérifient si vous comprenez réellement l’ordre — plutôt que si vous avez simplement mémorisé une règle — vous demanderont de prédire la sortie. Le faire mentalement et aboutir à la bonne réponse en est la preuve. La documentation de cppreference sur la construction des classes dérivées confirme cette séquence comme comportement spécifié.
Distinguez l’héritage de constructeurs du chaînage de constructeurs
Pourquoi les intervieweurs aiment cette distinction
L’héritage de constructeurs en C++ et le chaînage de constructeurs se ressemblent suffisamment pour que les candidats les confondent sous pression. Ce sont pourtant deux mécanismes différents. L’héritage de constructeurs (via `using Base::Base;`) consiste à exposer les constructeurs de la classe de base dans l’interface de la classe dérivée. Le chaînage de constructeurs (constructeurs délégués) consiste pour un constructeur d’une même classe à appeler un autre constructeur de cette même classe. Les confondre en entretien nuit à votre crédibilité — non pas parce que l’intervieweur serait tatillon, mais parce que cette confusion montre que vous n’avez pas réellement utilisé l’un ou l’autre de manière volontaire.
Ce que cela donne en pratique
La partie gauche correspond à l’héritage de constructeurs en C++ — vous faites remonter les constructeurs de base dans la classe dérivée afin que les appelants puissent construire directement des objets `Derived` avec les signatures de `Base`. La partie droite correspond à la délégation — des constructeurs d’une même classe s’appellent entre eux pour éviter de dupliquer la logique d’initialisation. Une phrase qui résume les deux : « L’héritage expose, la délégation réutilise. » Un candidat capable de la dire et d’indiquer la bonne syntaxe a répondu proprement au suivi.
Les deux mécanismes sont décrits dans les ajouts du standard C++11 documentés sur cppreference pour les constructeurs hérités, et les constructeurs délégués sont spécifiés dans la même révision du standard.
Répondez aux questions de suivi que les intervieweurs posent réellement ensuite
Qu’en est il de using Base::Base; en C++11 et au delà ?
La déclaration `using Base::Base;` indique au compilateur de générer des constructeurs dérivés correspondant à chaque signature de constructeur de base. C’est du sucre syntaxique — sous le capot, le sous-objet de base est toujours initialisé via la liste d’initialisation, et toutes les mêmes règles s’appliquent. Ce qui change, c’est le code répétitif : vous n’avez plus besoin d’écrire un constructeur dérivé pour chaque signature de constructeur de base juste pour transmettre les arguments.
Le piège consiste à croire que cela modifie la règle fondamentale. Ce n’est pas le cas. Le sous-objet de base doit toujours être construit. La classe dérivée ne peut ni remplacer ni ignorer l’initialisation de la base. `using Base::Base;` est une fonctionnalité de confort destinée à réduire la répétition, pas un mécanisme d’héritage réel des constructeurs au sens traditionnel. Les intervieweurs qui posent cette question testent généralement si le candidat comprend ce que cela fait, et ce que cela ne fait pas.
Que se passe t il avec les constructeurs de copie dans les hiérarchies d’héritage ?
Les constructeurs de copie et de déplacement suivent la même règle base d’abord. Lorsqu’un objet `Derived` est construit par copie, son constructeur de copie doit invoquer le constructeur de copie de `Base` — généralement via `: Base(other)` dans la liste d’initialisation, où `other` est l’objet `Derived` source (qui est aussi un `Base`). Si vous écrivez un constructeur de copie personnalisé pour `Derived` et que vous oubliez de copier la partie `Base`, le sous-objet de base est simplement construit par défaut, et vous perdez silencieusement tout l’état de la base.
C’est un vrai motif de bug en production, pas seulement un piège d’entretien. La règle est la même : la partie base est gérée séparément, dans la liste d’initialisation, et le constructeur dérivé est responsable de le faire correctement.
Pourquoi la troncature d’objet et le dispatch virtuel reviennent ils ici ?
La troncature d’objet et le dispatch virtuel sont tous deux liés au même problème sous-jacent : l’objet dérivé n’est pas toujours traité comme un objet dérivé.
La troncature se produit quand vous passez un objet `Derived` par valeur à une fonction qui attend un `Base`. La partie `Derived` est littéralement coupée — seul le sous-objet `Base` est copié. Aucune magie de constructeur n’empêche cela ; c’est une conséquence de la sémantique de valeur. La solution consiste à passer par pointeur ou par référence.
Le dispatch virtuel dans les constructeurs est un autre piège. Quand un constructeur de classe de base appelle une fonction virtuelle, le mécanisme de dispatch virtuel ne fonctionne pas comme vous pourriez l’attendre — le pointeur de vtable à ce moment-là correspond à la classe `Base`, pas à `Derived`, parce que `Derived` n’est pas encore entièrement construite. C’est donc la version de base de la fonction virtuelle qui s’exécute, pas la surcharge dérivée. Cela surprend les candidats qui pensent que virtuel signifie toujours « la plus dérivée ». Dans un constructeur (ou un destructeur), le type dynamique de l’objet est le type en cours de construction à cet instant. GotW #50 de Herb Sutter traite ce sujet en détail et mérite d’être lu avant tout entretien C++ de niveau senior.
Ne vous laissez pas piéger par l’héritage multiple et le diamant
Pourquoi l’héritage multiple change la donne
Avec une seule classe de base, l’ordre de construction est simple. Avec plusieurs classes de base, le compilateur les construit dans l’ordre où elles apparaissent dans la liste des bases de la définition de la classe — et non dans l’ordre où vous les écrivez dans la liste d’initialisation. Cette distinction piège les candidats qui pensent pouvoir contrôler l’ordre en réorganisant la liste d’initialisation. Ce n’est pas possible. L’ordre est fixé par la définition de la classe.
Le problème du diamant complique encore les choses : lorsque deux classes de base partagent un ancêtre commun, une implémentation naïve construit cet ancêtre deux fois — une fois par chaque chemin. L’héritage virtuel existe précisément pour fusionner ces deux copies en une seule, mais cela modifie la responsabilité de construction de la base partagée. Dans une hiérarchie à héritage virtuel, c’est la classe la plus dérivée qui est responsable de construire directement la base virtuelle, en contournant les appels de construction des classes intermédiaires vers celle-ci.
Ce que cela donne en pratique
Sans `virtual`, `A` serait construit deux fois dans `D`. Avec `virtual`, il n’existe qu’un seul sous-objet `A` partagé, et c’est `D` qui est responsable de le construire. Les appels `A(x)` dans les listes d’initialisation de `B` et `C` sont silencieusement ignorés lors de la construction via `D`. C’est contre-intuitif, et les intervieweurs le savent — c’est précisément pour cela qu’ils posent la question. Un candidat capable d’esquisser cette hiérarchie et d’expliquer pourquoi `D` doit initialiser `A` directement montre une vraie compréhension de la disposition des sous-objets.
La FAQ ISO C++ sur l’héritage virtuel traite ce point avec précision et constitue la bonne référence à citer si un intervieweur demande une source.
Comment Verve AI peut vous aider à préparer votre entretien sur l’héritage de constructeurs en C++
Le problème structurel que cet article vient de parcourir — connaître la règle, connaître l’ordre, connaître les pièges — s’apprend réellement en lisant. Ce qui est plus difficile à apprendre par la lecture, c’est de savoir si votre réponse orale donne l’impression que vous maîtrisez le sujet ou que vous le reconstruisez sous pression. Pour le candidat, ces deux états semblent identiques ; pour l’intervieweur, ils sont totalement différents.
C’est cet écart que Verve AI Interview Copilot est conçu pour combler. Il écoute en temps réel vos réponses pendant vos entraînements, réagit à ce que vous avez réellement dit plutôt qu’à une question générique, et fait remonter le suivi qu’un intervieweur poserait vraisemblablement ensuite — y compris ceux couverts dans ce guide, comme « et si le constructeur de base est private ? » ou « que se passe-t-il pour le dispatch virtuel dans un constructeur ? ». Verve AI Interview Copilot reste invisible pendant ce processus, de sorte que l’environnement d’entraînement reproduit la pression réelle d’un entretien sans vous offrir le filet de sécurité consistant à mettre en pause et à chercher une réponse.
La capacité particulière qui change la donne pour la préparation en C++ est que Verve AI Interview Copilot peut réagir à la formulation exacte que vous avez utilisée — si vous avez dit « la base s’exécute en premier » sans expliquer pourquoi, il vous renverra immédiatement vers le pourquoi, exactement comme le ferait un intervieweur senior. Cette boucle de rétroaction, répétée sur les pièges de ce guide, est ce qui transforme la connaissance en réponse que vous pouvez livrer sans hésitation.
Conclusion
Le script de 20 secondes est l’essentiel : les constructeurs ne sont pas hérités, le constructeur dérivé appelle le constructeur de base dans la liste d’initialisation, et la base est construite en premier et détruite en dernier. Dites cela clairement, esquissez la syntaxe de la liste d’initialisation et tracez l’ordre de construction — et vous aurez couvert la question centrale ainsi que les deux premiers suivis avant même que l’intervieweur n’ait besoin de vous relancer.
Les pièges — absence de constructeur par défaut, constructeurs de base privés, dispatch virtuel dans les constructeurs, diamant — ne sont que des prolongements de la même règle. Une fois que vous maîtrisez cette règle, les pièges deviennent prévisibles. Entraînez-vous à dire la réponse de base à voix haute avant votre prochain entretien. Pas à la lire. À la dire. La différence entre la connaître et être capable de la livrer sous pression est précisément l’écart que la préparation est censée combler.
Verve AI
Archives