Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C++ Question entretien C++ - doutes.

Question entretien C++ - doutes.

95 réponses
Avatar
David Fleury
Bonjour,

voici une des questions que je pose pour lors de mes entretiens pour des
développeurs avec expérience orienté C++

"Ecrire une fonction qui renverse une chaine (ex: ABC -> CBA, AE -> EA, ...)

Après avoir posé la question deux ou trois fois déjà, je suis surpris
des réponses (souvent fausses). Je laisse volontairement le choix au
candidat d'utiliser (char* ou std::string) et/ou une fonction modifiant
la chaine entrée ou retournant une nouvelle chaine, et l'utilisation de
la STL est autorisé.

A votre avis, est-ce que la question n'est pas trop mauvaise ?

David.

PS : Dans le même genre, il y a la fonction EstPalindrome qui semble
bloquer.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3 4 5 6 7
Avatar
Jean-Marc Bourguet
Michael DOUBEZ writes:

Wykaaa a écrit :
> Luc Hermitte a écrit :
>> On 28 oct, 09:59, Wykaaa wrote:
>>> Des questions pertinentes pour voir si le développeur maîtrise le C/C++
>>> seraient plutôt du style :
>>> - pt étant un pointeur sur tableau, puis-je écrire pt++
>>
>> Est-ce trop évident pour qu'il y ait un truc qui m'échappe quant à ce
>> que cette question teste ?
> Un pointeur sur tableau est constant, il ne peut être modifié. Ca peut
> paraître évident mais nombreux sont ceux qui se font piéger en
> entretien...

Est ce que piéger le candidat est le but ?



Non, je crois que le but est de voir si le candidat a les idees claires
dans les relations entre pointeur et tableau, ce qui est un point de
confusion important et un bon test de competance (bon test pour les
bouquins aussi d'ailleurs). Quand j'interviewe pour du C, je pose des
questions -- moins ambigues, j'espere -- dans ce but. En C++, je ne le
ferais que si le candidat aborde lui-meme ce sujet.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
James Kanze
On Oct 29, 10:19 am, Jean-Marc Bourguet wrote:
"Alex" writes:
> "Jean-Marc Bourguet" wrote in message
> >> Oui, à la limite aux débutants, et encore.
> >> Quand tu as > ans d'expérience, tu ne codes plus "à la
> >> main" : tout se fait en copier-coller.



> > Tu vis dans un autre monde que le mien.



> Oui, dans le monde réel, où tout est sur google ou google
> groups et où on n'a pas de temps à perdre à réinventer la
> roue...



C'est peut-etre *un* monde reel, mais ce n'est pas le mien.
J'ai la chance de devoir faire quelque chose qui n'a pas deja
ete fait et mis a la disposition de tout le monde.



Je crois que c'est le cas dès qu'il s'agit d'exiger une certaine
qualité et que l'application a une certaine complixité. Sans
parler des problèmes de license : si tu veux vendre un
compilateur, tu ne vas pas faire du copier/coller de g++.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
James Kanze
On Oct 29, 7:36 pm, Luc Hermitte wrote:
On 28 oct, 09:59, Wykaaa wrote:



> Des questions pertinentes pour voir si le développeur
> maîtrise le C/C++ seraient plutôt du style :
> - pt étant un pointeur sur tableau, puis-je écrire pt++



Est-ce trop évident pour qu'il y ait un truc qui m'échappe
quant à ce que cette question teste ?



Il me semble pourtant évident : donné
Type (*pt)[N];
, est-ce que pt++ est légal ? (Littéralement, évidemment, je
peux toujours écrire pt++. Selon ce que c'est pt, le compilateur
va peut-être le rejeter, mais rien ne m'empêche de l'écrire.
Mais je suis sûr que l'intention n'était pas de le prendre aussi
littéralement que ça.) La réponse est donc clairement oui, en ce
qui concerne le compilateur, et que ça dépend de ce auquel
pointe pt s'il y a un comportement indéfini ou non.

Mais franchement, ce n'est pas le genre de question que je
poserais. D'après ce que j'ai vu, les pointeurs vers des
tableaux sont un aspect plutôt exotique de C++ (ou de C), et ils
servent assez rarement. (Mais peut-être je me trompe en ce qui
concerne le C ; peut-être dans des domaines où il y a beaucoup
de tableaux à deux dimensions ou plus.)

[...]
Dans de la "vieille" prose [1] sur le sujet j'estimais que :
- d'abord, il faut savoir ce que l'on cherche : un cador du C++,
quelqu'un qui saura développer en C++ ce qu'on lui demande, quelqu'un
qui saura l'apprendre et évoluer, etc ?



Quelqu'un qui saurait faire du mentoring, et conseiller les
autres quand ils ont des problèmes C++ ardus ?:-) (C'est une
partie essentielle de mon rôle ici.)

- ensuite, quitte à poser des questions, je préfère encore les
questions plus vicieuses qui testent si en face on a un initié
qui va voir les contre-idiomes d'un petit exemple simple, et
qui permettent malgré tout aux non initiés de montrer ce
qu'ils ont vu en cours sans être découragés. Après, on peut
sélectionner aux nombres de contre- diomes détectés et autres
WTF émis.



Je ne sais pas. La dernière fois que j'avais à valider les
compétences des candidats, je trouveais que 9 sur 10 s'heurter
sur des questions aussi simple que « Pourquoi est-ce qu'on
déclarerait un destructeur virtuel ? ». Un (avec soi-disant 2
ans d'expérience avec C++ dans un projet OO) m'a même démandé ce
que j'entendais par « virtuel ».

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
James Kanze
On Oct 29, 11:38 pm, Wykaaa wrote:
Luc Hermitte a écrit :



> On 28 oct, 09:59, Wykaaa wrote:
>> Des questions pertinentes pour voir si le développeur maîtrise le C/C++
>> seraient plutôt du style :
>> - pt étant un pointeur sur tableau, puis-je écrire pt++



> Est-ce trop évident pour qu'il y ait un truc qui m'échappe
> quant à ce que cette question teste ?



Un pointeur sur tableau est constant, il ne peut être modifié.
Ca peut paraître évident mais nombreux sont ceux qui se font
piéger en entretien...



Pardon, mais une variable n'est const que si tu la déclares
const. Quelque soit son type. Le fait que le type soit pointeur
sur tableau n'y change rien.

>> - Pourquoi, quand on surcharge l'opérateur [], vaut-il mieux le
>> surcharger dans sa version const et non const ?
>> - Que signifie une dérivation virtuelle et à quoi cela sert-il ?
>> - Comment interdire l'utilisation de l'affectation entre instances d'u ne
>> classe ?
>> - Comment surcharge-t-on l'opérateur ++ dans sa version préfixe et dans
>> sa version postfixe ?
>> - Quelles sont les différentes utilisations de l'opérateur de "sco pe" :: ?



> Ce sont principalement des questions de cours dont la
> réponse se trouve en peu de temps avec un navigateur
> internet. La surcharge de ++ me faisant à peu près le même
> genre d'effet que de mélanger virgules et points-virgules
> pour voir la réaction du candidat.



Je suppose qu'un candidat au poste n'a pas à sa disposition un
navigateur lors de l'entretien !



C'est donc que l'entretien ne reflette pas les conditions réeles
du travail. Dans la pratique, les deux dernières questions
ci-dessus sont sans intérêt réel. Et la réponse à la troisième
de la fin doit être : selon la façon qui est préconsisée dans
les règles de programmation locales. Une meilleur question
serait de démander quand on voudrait le faire. Ce qui pourrait
mener à une discussion intéressante sur les différences entre
les entités et les valeurs, ou sur les interactions entre le
polymorphisme et l'affectation. Ce qui mène à la suggestion de
Luc (qui m'a beaucoup plu) de commencer avec un anti-patterne ;
démande au candidat de dériver d'une classe avec affectation, et
voir ce qu'il fait avec l'opérateur d'affectation.

> Dans de la "vieille" prose [1] sur le sujet j'estimais que :
> - d'abord, il faut savoir ce que l'on cherche : un cador du
> C++, quelqu'un qui saura développer en C++ ce qu'on lui
> demande, quelqu'un qui saura l'apprendre et évoluer, etc ?



Exactement. Il faut tout d'abord définir ce que l'on cherche
et les objectifs.



Et c'est bien plus difficile d'évaluer sa capacité de travailler
en équipe ou de communiquer qu'il ne l'est d'évaluer ses
compétences C++. Alors qu'à la rigueur, le C++ s'apprend, tandis
que la capacité de travailler en équipe et de communiquer
clairement ses idées, plus difficilement.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
James Kanze
On Oct 30, 8:42 am, David Fleury wrote:
Wykaaa a écrit :



> Luc Hermitte a écrit :



>> On 28 oct, 09:59, Wykaaa wrote:
>>> Des questions pertinentes pour voir si le développeur
>>> maîtrise le C/C++ seraient plutôt du style :
>>> - pt étant un pointeur sur tableau, puis-je écrire pt++



>> Est-ce trop évident pour qu'il y ait un truc qui m'échappe
>> quant à ce que cette question teste ?



> Un pointeur sur tableau est constant, il ne peut être
> modifié. Ca peut paraître évident mais nombreux sont ceux
> qui se font piéger en entretien...



Vu comment la question était posée, j'aurais clairement
compris autre chose.



int tab[25] = { ... }; // un tableau
int* ptr = &tab[0]; // un pointeur sur le premier élément du tab leau



++ptr; // élément suivant



Mais où est le pointeur sur tableau là-dedans. Plutôt :
int (*ptr)[ 25 ] = &tab ;
, il me semble. C'est au moins ce que je m'entends par
« pointeur sur tableau ».

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
James Kanze
On Oct 30, 8:41 am, ld wrote:
On 28 oct, 19:13, David Fleury wrote:



[...]
En particulier avec C++, la capacite a faire un bon design est
essentielle dans un "vrai" projet.



Ce n'est pas particulier avec C++ ; une bonne conception est
essentielle, quelque soit le langage. Mais la question reste :
quelle est la poste à pourvoir ? Dans des grandes équipes, il y
a beaucoup de programmeurs qui n'ont qu'à implémenter des
éléments d'une conception qui leur est donnée. (Dans un projet,
au moins, environ 80% des développeurs n'avaient même pas le
droit de toucher aux fichiers d'en-tête. Qui était de toute
façon générée à partir du modèle par Rational Rose.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
Wykaaa
James Kanze a écrit :
On Oct 30, 8:42 am, David Fleury wrote:
Wykaaa a écrit :



Luc Hermitte a écrit :





On 28 oct, 09:59, Wykaaa wrote:
Des questions pertinentes pour voir si le développeur
maîtrise le C/C++ seraient plutôt du style :
- pt étant un pointeur sur tableau, puis-je écrire pt++









Est-ce trop évident pour qu'il y ait un truc qui m'échappe
quant à ce que cette question teste ?







Un pointeur sur tableau est constant, il ne peut être
modifié. Ca peut paraître évident mais nombreux sont ceux
qui se font piéger en entretien...





Vu comment la question était posée, j'aurais clairement
compris autre chose.



int tab[25] = { ... }; // un tableau
int* ptr = &tab[0]; // un pointeur sur le premier élément du tableau



++ptr; // élément suivant



Mais où est le pointeur sur tableau là-dedans. Plutôt :
int (*ptr)[ 25 ] = &tab ;
, il me semble. C'est au moins ce que je m'entends par
« pointeur sur tableau ».



Je souhaite apporter un éclaircissement sur le sujet.
En fait, emporté par le sujet, j'ai très mal formulé cette question.

Je voulais dire, en fait :
pt étant un nom de tableau peut-on écrire pt++ ?
La réponse est évidemment non puisqu'un nom de tableau est un pointeur
constant sur le premier élément du tableau.

Encore mille excuses pour cette mauvaise formulation qui a rendu la
discussion imprécise.
Avatar
ld
On 30 oct, 10:37, James Kanze wrote:
On Oct 30, 8:41 am, ld wrote:

> On 28 oct, 19:13, David Fleury wrote:

    [...]

> En particulier avec C++, la capacite a faire un bon design est
> essentielle dans un "vrai" projet.

Ce n'est pas particulier avec C++ ; une bonne conception est
essentielle, quelque soit le langage.



Je considère que c'est encore plus critique sur les langages
statiquement typés avec peu/pas de fonctionnalités dynamiques comme C
et C++ et où le manque de flexibilité du design se paye au prix fort.
Le minimum étant les interfaces à-la-Java que malheureusement C++ n'a
pas (mais pourrait).

Mais la question reste :
quelle est la poste à pourvoir ? Dans des grandes équipes, il y
a beaucoup de programmeurs qui n'ont qu'à implémenter des
éléments d'une conception qui leur est donnée. (Dans un projet,
au moins, environ 80% des développeurs n'avaient même pas le
droit de toucher aux fichiers d'en-tête. Qui était de toute
façon générée à partir du modèle par Rational Rose.)



Tout à fait d'accord. Mais comme je n'ai jamais travaillé dans une
"grande" équipe (>20) et comme je crois que c'est somme toute assez
rare, je n'avais pas considéré ce cas de figure. Autant pour moi. Ceci-
dit, je n'aime les projets où on considère les programmeurs comme des
générateurs de code et où leur rôle est ultra spécialisé. Mon c oté
créatif sans doute ;-)

a+, ld.
Avatar
Michael DOUBEZ
Wykaaa a écrit :
[snip]
Je voulais dire, en fait :
pt étant un nom de tableau peut-on écrire pt++ ?
La réponse est évidemment non puisqu'un nom de tableau est un pointeur
constant sur le premier élément du tableau.



Comme d'autre l'ont signalé, le om d'un tableau est de type tableau et
non pas de type pointer. Pour des raisons historiques (K&R C), le
tableau se converti implicitement en pointeur mais il reste un tableau.

D'ailleur:
int * const ptr;
const int tab[42];
int * const ptr=tab;

sizeoff(ptr)!=sizeof(tab)

--
Michael
Avatar
Michael DOUBEZ
ld a écrit :
On 30 oct, 10:37, James Kanze wrote:
On Oct 30, 8:41 am, ld wrote:

On 28 oct, 19:13, David Fleury wrote:


[...]

En particulier avec C++, la capacite a faire un bon design est
essentielle dans un "vrai" projet.


Ce n'est pas particulier avec C++ ; une bonne conception est
essentielle, quelque soit le langage.



Je considère que c'est encore plus critique sur les langages
statiquement typés avec peu/pas de fonctionnalités dynamiques comme C
et C++ et où le manque de flexibilité du design se paye au prix fort.



C'est d'autant plus vrai pour les langages dynamiques où il est
nécessaire d'avoir une bonne couverture de test et où l'architecture est
pressurés par la testabilité.

Le minimum étant les interfaces à-la-Java que malheureusement C++ n'a
pas (mais pourrait).



Quel est le problème avec les classes virtuelles pures ?

struct IConnectable
{
virtual connect()=0;
virtual disconnect()=0;
};

Je dirai plutôt que c'est Java qui n'a pas voulu des héritages multiples.


Mais la question reste :
quelle est la poste à pourvoir ? Dans des grandes équipes, il y
a beaucoup de programmeurs qui n'ont qu'à implémenter des
éléments d'une conception qui leur est donnée. (Dans un projet,
au moins, environ 80% des développeurs n'avaient même pas le
droit de toucher aux fichiers d'en-tête. Qui était de toute
façon générée à partir du modèle par Rational Rose.)



Tout à fait d'accord. Mais comme je n'ai jamais travaillé dans une
"grande" équipe (>20) et comme je crois que c'est somme toute assez
rare, je n'avais pas considéré ce cas de figure. Autant pour moi. Ceci-
dit, je n'aime les projets où on considère les programmeurs comme des
générateurs de code et où leur rôle est ultra spécialisé. Mon coté
créatif sans doute ;-)



Ça dépends de la taille du projet. Typiquement, il y a un groupe de
développeur qui est là du début à la fin (core team) et d'autres qui
viennent en renfort à certains points clés de la vie du projet (en
général au milieu). Ceux qui viennent aider ne sont pas moins créatifs
même si il est peut probable qu'ils prennent une décision qui va
influencer le cours du projet.

--
Michael
3 4 5 6 7