Cinq mythes courants sur le C++ (traduction d'un article de Bjarne Stroustrup)

Bonjour à tous,

Je viens de publier une traduction d'un article de Bjarne Stroustrup discutant de Cinq mythes courants sur le C++.

Je trouve que cet article est intéressant non seulement pour ceux qui débutent en C++, mais aussi pour ceux qui connaissent un langage qui fait partie de la même famille (C, C#, Java...) et qui voudraient avoir une idée de ce qui caractérise le C++, de ce qui lui est spécifique.

N'hésitez pas à laisser vos commentaires !

PS : Suite à l'article et aux nombreuses remarques qu'il a suscitées, Bjarne a aussi publié une postface (pas encore traduite).

Bonjour et merci pour cette traduction, l'article est intéressant.

Je n'ai pas fini de le lire mais je pose une question. A plusieurs reprise les exemples de code donnés utilisent des accolades {} là où j'aurais naturellement mis des parenthèses ().

Code:

---

1 2 3 4 5 6

void user2() { Filter flt {"books","authors"}; unique_ptr<Filter> p {new Filter{"novels","favorites"}}; // on utilise flt et *p }

---

Dans cet exemple, je pensais qu'il était impossible d'utiliser des accolades pour passer les 2 arguments au constructeur de Filter. S'agit-il d'un des standard de C++ ou d'une erreur de recopie/traduction ?

Il s'agit de "nouvelles" notations introduites avec le C++11, en 2011.

C'est possible à partir du C++11, et ça permet une syntaxe d'initialisation plus uniforme dans les différents cas (même si les autres syntaxes d'initialisation restent possibles pour compatibilité, voire même indispensables dans certains cas). Une des nouveautés appréciables apportées par cette syntaxe est la capacité d'initialiser des collections :

Code:

---

map<string, string> m {{"Hello", "Bonjour"}, {"World", "Monde"}};

---

En tant que promoteur principale de cette syntaxe, Bjarne l'utilise systématiquement dans ses articles. Et l'idée est que si on souhaite n'apprendre qu'une seule syntaxe à quelqu'un, autant apprendre celle là.

Ok, je connaissais la nouvelle syntaxe pour initialiser un liste en passant toutes les valeurs séparées par des virgules, le tout entre accolades. Mais la possibilité d'utiliser cette syntaxe pour initialiser un objet classique m'avait complètement échappé. Je m'en vais trouver un peu de doc là dessus.
Merci

Un point d'entrée comme un autre, list initialization sur cppreference.com.

Mouai, intéressant mais surtout destinés a ceux qui commencent le C++ aujourd'hui et en utilisant des bibliothèques modernes et non pas des vieux machins legacy d'il y a 20+ ans.

Pour les vieux fossiles comme moi, a l’époque le char* était plus courant que le string, la lib standard C++ était peanuts, et la majorité des libs externes étaient écrites en C ou en C++ C-like. Donc oui ça avait beaucoup beaucoup plus de sens de commencer par C a l'epoque. Mais cela concernait les versions de C++ circa 96-98-01. Évidement c'est moins évident que de commencer directement en C++ '11. Porter l’intégralité d'un programme ou d'un framework pre-existant (donc écrit a l'ancienne) demande des investissements (entre autre dans mon cas la formation de scientifiques et mathématiciens qui développent des modèles) qu'on ne peut pas tout le temps se permettre (ou ne veut pas dans leur cas).

Pour le reste non, bien que The C++ Programming Language ~ Special Edition de Stroustrup (livre qui, a nouveau, concerne des anciennes versions de C++) trône sur mes étagères derrière moi depuis plus de 10 ans bien que je fasse du C++ assez régulièrement, j'ai toujours une réaction de rejet quand j'essaie de lire la doc d'une classe ou d'une méthode de fonction a 45 (j’exagère) arguments génériques imbriquées dont ni le nom ni la doc ne m'explique clairement ce a quoi ils ou elle servent. Probablement une déformation de faire du Java (que d'aucun trouvent trop verbeux justement a cause des noms trop long et trop explicites). Ceci dit les dernières évolutions de Java 8 font que désormais on peut retrouver cette même complexité de compréhension en utilisant trop de génériques et de lambda pour reduire un bloc de code a une instruction d'une seule ligne donc en gros on a atteint le même niveau.

Ensuite, n'essaie-t-il pas de prêcher des convertis ? Je veux dire, prenons les sessions vidéo de la dernière conf C++ qui ont été publié ici sur Developpez. Rien que les sessions présentées par Ubisoft sont quand même parlantes : si on veut de la perf brute (et dans le cas d'Ubi de la portabilité sur les plateformes de jeux via leurs framework maison), on fait du C++. Pour eux le C# ne sert que pour les outils middleware qu'ils utilisent en interne ; le produit qui sera publié et vendu sera lui écrit en C++ principalement.

Il est évident que les évolutions des langages (ou les nouveaux langages) ne vont pas intéresser ceux qui n'ont pas évolué depuis 20 ans.
Par contre, ces évolutions ne vont pas intéresser que les débutants, mais également ceux qui ont compris que le coût de mise a niveau de ses connaissances et des projets est largement compensé par les résultats obtenus (efficacité pour écrire des programmes et surtout corriger les problèmes).

Beaucoup de ceux qui continue de faire du C++ old school ne le font pas parce qu'ils maîtrisent le C++ old school (beaucoup de codes C++ old school sont crades, en particulier sur la gestion des erreurs).
Il y a pleins de personnes sur ce forum qui travaillent sur du code ancien ou avec des scientifiques, ce n'est pas forcement impossible de faire évoluer les choses.

Merci Loïc pour cette traduction. J'ai trouvé cet article très intéressant.

Je suis tout à fait d'accord avec les points cités par Bjarne.

Pour moi si ces problèmes perdurent, c'est qu'on ne va pas à la source des problèmes, voici quelques facteurs qui font que pour moi on reste dans le passé avec le C++ :

• Les vielles distributions à l'école avec GCC et C89 (ou G++).
• Les compilateurs plus récents (je pense à GCC) qui n'activent pas par défaut C++11/14 (ps : en espérant que cela ait changé depuis...)
• Beaucoup de tutoriel sur internet, mais la plupart sont nuls, on ne montre pas toutes les possibilités offertes par C++11/14 (je pense aux variétés de pointeur intelligent ou aux threads par exemple).

Autrement l'impression que j'ai eu il y a quelques années lorsque j'apprenais le C++ sur les forums (SdZ principalement à l'époque) est que les gens (peut-être des "vieux") avaient un manque de volonté phénoménal à vouloir partager leurs connaissances (ils ne s'aidaient vraiment entre eux que lorsque les sujets abordés leurs semblaient suffisamment "intéressant"). D'ailleurs j'avais lu quelque part une personne du forum (developpez) avoir eu le même ressenti pour le langage Java à une certaine époque mais que les choses avaient changés depuis l'expansion de C# et PHP pour le web (peut-être la peur de voir sa communauté disparaitre à cause des concurrents). Par contre pour le langage PHP je n'ai jamais eu de mauvais retour, peut-être parce que c'est un langage à la base plus ouvert de par sa simplicité et que la volonté de sa communauté (dont non informaticien) n'est pas de garder le "secret" des connaissances pour eux-même.
Bien sûr les choses ont beaucoup changé depuis je pense, un problème fréquent rencontré ? Et hop go sur stack.
Bref c'était mon ressenti, vous pouvez ne pas être d'accord.

Citation:

---

Envoyé par bouye

Mouai, intéressant mais surtout destinés a ceux qui commencent le C++ aujourd'hui et en utilisant des bibliothèques modernes et non pas des vieux machins legacy d'il y a 20+ ans.

---

L'article en lui même vise surtout les "anciens" comme nous, car justement beaucoup n'ont pas encore intégré le fait qu'il y avait des exceptions en C++, ou ne serait-ce ce que les destructeurs peuvent faire pour nous -- là, je suis toujours en C++98/03. Et aussi ceux qui n'ont pas encore eu le temps de regarder, ensuite, ce que les C++11 et 14 apportent.

Après, il y a certes les problèmes de base vieilles bases de code, et de compilos limités par les distribs linux/windows. Mais cela n'empêche en rien de former les gens à développer dans un C++ plus moderne.

Citation:

---

Envoyé par Gugelhupf

Autrement l'impression que j'ai eu il y a quelques années lorsque j'apprenais le C++ sur les forums (SdZ principalement à l'époque) est que les gens (peut-être des "vieux") avaient un manque de volonté phénoménal à vouloir partager leurs connaissances (ils ne s'aidaient vraiment entre eux que lorsque les sujets abordés leurs semblaient suffisamment "intéressant").

---

C'est un phénomène classique. On forme une première fournée de débutants, et petit à petit on leur refile les réponses simples. Si on voit que les questions simples sont pas ou mal traitées, on intervient. Mais il arrive, il est vrai, que l'on finisse par en avoir marre de répondre aux mêmes exos très basiques (car après tout, on ne doit rien à personne quand on répond bénévolement), ou aux questions où les choses deviennent inutilement des usines à gaz (un effet pervers est que l'on ne tient pas à se prendre le choux sur des codes d'autres personnes qui sont à l'ancienne quand on a déjà nos bases de codes à maintenir/moderniser, et de fait on voit une recrudescence de "bashage de profs qui apprennent le C++ old school").
Cela me fait penser "Hacker guide" d'Eric Raymond qui décrit (entre autres), un phénomène très similaire, IIRC.

Bonjour,

Citation:

---

Envoyé par JolyLoic

C'est possible à partir du C++11, et ça permet une syntaxe d'initialisation plus uniforme dans les différents cas (même si les autres syntaxes d'initialisation restent possibles pour compatibilité, voire même indispensables dans certains cas). Une des nouveautés appréciables apportées par cette syntaxe est la capacité d'initialiser des collections :

Code:

---

map<string, string> m {{"Hello", "Bonjour"}, {"World", "Monde"}};

---

En tant que promoteur principale de cette syntaxe, Bjarne l'utilise systématiquement dans ses articles. Et l'idée est que si on souhaite n'apprendre qu'une seule syntaxe à quelqu'un, autant apprendre celle là.

---

J'avoue que je ne comprend pas vraiment son raisonnement. Comme tu l'as dit :

Citation:

---

même si les autres syntaxes d'initialisation restent possibles pour compatibilité, voire même indispensables dans certains cas

---

En effet, si on a :

Code:

---

1 2 3 4

class C{ C( std::initializer_list<int>() values ); // (1) C(int taille, int default value = int() ); // (2) };

---

Alors :

Code:

---

1 2 3 4 5

C(5,5) C{5,5}   C(4) C{4}

---

Ne font pas du tout la même chose, c'est donc, de mon avis, un hérésie de mélanger les deux.
En effet, si on n'utilise que {}, il y a de fortes chances qu'on ne fasse pas la distinction entre {} et () ce qui sera très préjudiciable par la suite.
Autant se dire tout de suite : () = constructeur normal et {} = constructeur par liste d'initialisation.

Imaginons qu'on ai uniquement le constructeur (2) et qu'on utilise des accolades. On décide ensuite d'ajouter le constructeur (1) quelques mois plus tard. Que fait-on par la suite ? On réécrit tout notre code ? On oublie certaines partie et on laisse des {} là où il faudrait maintenant des () ?

De plus, je ne comprend pas l'argument d'uniformisation, pour moi, c'est encore moins uniforme !
Pour les initialiseurs, {}
Pour les autres constructeurs, {} ou () si un initialiseur d'arguments "similaire" existe.

Citation:

---

Envoyé par Neckara

De plus, je ne comprend pas l'argument d'uniformisation, pour moi, c'est encore moins uniforme !

---

C'est plus uniforme car la même syntaxe est utilisée pour constructeurs par initializer_list et les constructeurs classiques. C'est le seul moyen pour écrire des constructions de collections imbriquées. L'ancienne syntaxe doit être conservée car la rétro-compatibilité est une feature en C++.

Citation:

---

Envoyé par Neckara

Imaginons qu'on ai uniquement le constructeur (2) et qu'on utilise des accolades. On décide ensuite d'ajouter le constructeur (1) quelques mois plus tard. Que fait-on par la suite ? On réécrit tout notre code ? On oublie certaines partie et on laisse des {} là où il faudrait maintenant des () ?

---

Pour cette même raison, si tu conçois ton code de sorte à ce que n'utiliser que la notation {} donne un code valide, le problème ne se posera pas. Et s'il se pose, si tu utilises la différence ce notation pour lever l'ambiguité, il y a un risque de mal utiliser le code car les deux syntaxes sont quand même disponibles. Oui, ça peut introduire des confusions, c'est un défaut notable, mais que perso je considère acceptable au regard du gain.

Citation:

---

Envoyé par jblecanard

C'est plus uniforme car la même syntaxe est utilisée pour constructeurs par initializer_list et les constructeurs classiques.

---

Sauf dans le cas où on a les deux (initializer_list et les constructeurs classiques) possibles pour les même arguments.
Imagine aussi, tu veux appeler C(int, int).
Tu vas mettre des {} par habitude. Grossière erreur, il faut au préalable et systématiquement vérifier si ta classe C ne possède pas de constructeur avec initializer_list pouvant "matcher".
Je ne pense pas que ce soit vraiment pratique pour l'utilisateur, et pire encore pour le débutant.
Le pauvre qui n'arrivera pas à comprendre pourquoi sa classe n'est pas initialisée comme il le souhaiterait :aie:.

Je trouve qu'il est plus simple de lui dire "utilise ()".
Puis plus tard, quand on voit les initializer_list, lui dire "utilise {} pour les initializer_list".

Plutôt que de lui dire "utilise {}" et quand il a pris l'habitude d'utiliser les {}, on lui montre les initializer_list et on lui dit, "on t'as menti, en fait c'est pas toujours {}, parfois faut utiliser ()".
Ou alors travailler en C++90 sur des projets et en C++11 sur d'autres, passer de () à {} et inversement, cela peut vite devenir soûlant.

Je ne parle pas de la configuration des IDE pour les auto-complétion et extraits de codes…

Citation:

---

Et s'il se pose, si tu utilises la différence ce notation pour lever l'ambiguité

---

Donc on doit modifier tout code qui utilise notre classe ? :aie:
Cela va à l'encontre des bon principes de programmations.

Encore pire si notre classe fait partie d'une bibliothèque utilisée par d'autres…

Citation:

---

perso je considère acceptable au regard du gain.

---

J'ai, personnellement du mal à voir le gain apporté par l'utilisation de {} pour le constructeur au lieu de ().

@Neckara
Je te conseille très fortement la lecture de Effective Moderne C++, de Scott Meyers

Pour la confusion entre () et {} lorsque tu as un initializer_list constructor est effectivement problématique (Scott Meyers parle même d'une erreur de conception de vector).
Donc si tu as une classe qui n'a pas de constructeur par liste, tu ne dois surtout pas l'ajouter dans un second temps. Sinon, comme tu l'as dit, cela peut provoquer un changement de comportement du code, qui serait indétectable et donc galère à corriger.
Le problème ne se pose pas si on passe d'un code C++03 et qu'on compile avec un compilateur C++11 (qui ajoute donc par exemple std::vector(initializer_list) ) puisque l'ancien code n'utilisait pas les {}

En termes d'enseignements, cela veut dire effectivement que l'on ne peut pas dire "il faut utiliser {}" ou "il faut utiliser ()". Cela dépend. Et c'est donc plus complique à expliquer.
Il faut probablement éviter d'utiliser les initializer_list constructor, excepté dans les rares cas de création d'une classe "conteneur" (type vector, list, etc). Dans ce cas, on peut considérer que l'utilisateur sait qu'il y a une différence entre () et {}, du fait que la STL utilise aussi cette approche.

Pour l'utilisation de "uniform initialisation", cela vient du fait qu'en C++03, il n'est pas toujours possible d'utiliser = ou () pour initialiser une variable. Alors que {} sera toujours utilisable :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

int x(0); // ok int x = 0; // ok int x{0}; // ok   int x(); // problème // pas de default initialization avec = int x{}; // ok   int x[] = { 1, 2, 3}; // ok vector<int> x = { 1, 2, 3}; // ok en C++11, pas en C++03   class A { int x(0); // erreur int x = 0; // ok int x{0}; // ok };   // class non copiable atomic<int> x(0); // ok atomic<int> x = 0; // erreur atomic<int> x{0}; // ok

---

Il y a d'autres problèmes avec () et {}, en particulier concernant la déduction automatique des types avec auto ou dans les templates, ce qui influence comment on doit écrire et appeler ce type de fonction. Cf le livre pour les détails

Citation:

---

Envoyé par mintho carmo

Je te conseille très fortement la lecture de Effective Moderne C++, de Scott Meyers

---

Le problème, c'est que je suis dans une période où je n'ai pas forcément beaucoup de temps :aie:.

Citation:

---

Pour la confusion entre () et {} lorsque tu as un initializer_list constructor est effectivement problématique (Scott Meyers parle même d'une erreur de conception de vector). Donc si tu as une classe qui n'a pas de constructeur par liste, tu ne dois surtout pas l'ajouter dans un second temps. Sinon, comme tu l'as dit, cela peut provoquer un changement de comportement du code, qui serait indétectable et donc galère à corriger.

---

Dans ce cas là, pourquoi ne pas interdire l'ambiguïté au niveau du compilateur/norme ?

Et dans le cas du vecteur, quel serait la "bonne solution" ?
Ne pas pouvoir ajouter l'initializer_list après coup est aussi relativement dommage.

Citation:

---

Il faut probablement éviter d'utiliser les initializer_list constructor, excepté dans les rares cas de création d'une classe "conteneur" (type vector, list, etc). Dans ce cas, on peut considérer que l'utilisateur sait qu'il y a une différence entre () et {}, du fait que la STL utilise aussi cette approche.

---

Le C++ a plutôt, je pense, une philosophie, "soyons idiot-proof". Ex. cast implicite des void * en C est interdit en C++.
Partir du principe que l'utilisateur connaît la différence me semble être, à mon sens, une erreur.

Citation:

---

Pour l'utilisation de "uniform initialisation", cela vient du fait qu'en C++03, il n'est pas toujours possible d'utiliser = ou () pour initialiser une variable. Alors que {} sera toujours utilisable :

---

Je vois.

int x();On déclare une fonction, il faudrait utiliser
int x;ce qui perd parfois des utilisateurs, en effet.

Mais d'un autre côté, int x{};, c'est deux caractère de trop pour moi, développeur fainéant.

Code:

---

1 2	int x[] = { 1, 2, 3}; // ok vector<int> x = { 1, 2, 3}; // ok en C++11, pas en C++03

---

Donc là, c'est les initializer_list.

Code:

---

1 2 3 4 5

class A { int x(0); // erreur int x = 0; // ok int x{0}; // ok };

---

C'est à mon sens le problème le plus gênant, en effet.
Mais j'aurais plutôt préféré autoriser int x(0) que "d'interdire sans interdire" l'ambiguïté c(int), c(intializer_list).

C'est d'ailleurs surtout cela qui me gêne.

Citation:

---

Envoyé par Neckara

Dans ce cas là, pourquoi ne pas interdire l'ambiguïté au niveau du compilateur/norme ?
Et dans le cas du vecteur, quel serait la "bonne solution" ?

---

Il faudrait voir les discussions qui ont menées a ce choix. Mais c'est clairement un choix qui a été fait volontairement (pas un effet indésirable non prévu) a priori.
Les initializer_list constructor sont prioritaires sur les autres constructeurs, si tu écris :

Code:

---

vector<double> v { static_cast<size_t>(1) };

---

Il y aura une conversion int vers double puis appel du constructeur par liste, même si le constructeur vector(size_t) correspond mieux

Citation:

---

Envoyé par Neckara

Ne pas pouvoir ajouter l'initializer_list après coup est aussi relativement dommage.

---

Si tu n'as pas une sémantique de conteneur, la question ne se pose pas, cela n'a pas de sens d'ajouter ce constructeur.
Si tu as une sémantique de conteneur, il faut effectivement faire le choix des le début. A mon sens, le plus simple est de respecter l'API de la STL et proposer ce constructeur (au pire, tu mets un static_assert(false, "don't do that!") dedans pour explicitement interdire son utilisation :) )

Citation:

---

Envoyé par Neckara

Le C++ a plutôt, je pense, une philosophie, "soyons idiot-proof". Ex. cast implicite des void * en C est interdit en C++.
Partir du principe que l'utilisateur connaît la différence me semble être, à mon sens, une erreur.

---

Si c’était "idiot proof", il n'y aurait pas du tout de void*.

Je ne voulais pas dire qu'il fallait partir du principe que l'utilisateur connait cette différence. Je voulais dire que ce problème existe, indépendamment de ce que tu feras. Le comité aurait probablement du voir ce problème plus en détail, mais pour le moment, il existe.
Donc tu peux partir du principe que tu n'introduis pas de nouvelle difficultés en faisant cela, tu utilises une difficulté existante. Le seul moyen pour éviter cette difficulté est de ne pas utiliser les initializer_list...

Citation:

---

Envoyé par Neckara

int x;ce qui perd parfois des utilisateurs, en effet.

Mais d'un autre côté, int x{};, c'est deux caractère de trop pour moi, développeur fainéant.

---

Attention, c'est pas la même chose.
Dans le premier cas, tu as une default-initilization, dans le second tu as une value initialization.
Pour un objet avec constructeur, tu vas appeler le constructeur par défaut dans les 2 cas.
Pour un build-in type, tu vas avoir une variable qui aura une valeur aléatoire dans le premier cas et une "zero initialization" dans l'autre (selon le type : 0, false, nullptr, etc)

HS : pour ajouter a la confusion (pour les débutants), selon la position des parenthèses, tu as une déclaration de fonction ou d'un valeur :

Code:

---

1 2	int i(); // declaration d'une fonction int(); // creation d'un int

---

Citation:

---

Envoyé par Neckara

Donc là, c'est les initializer_list.

---

C'est le constructeur par liste pour vector et une aggregate initialization pour le tableau style C.

Citation:

---

Envoyé par Neckara

Mais j'aurais plutôt préféré autoriser int x(0) que "d'interdire sans interdire" l'ambiguïté c(int), c(intializer_list).
C'est d'ailleurs surtout cela qui me gêne.

---

Tu n'es pas le seul :)
Je crois qu'il y a des discussions sur ce point, il faudrait vérifier.
Pour le moment, on doit continuer a expliquer les différentes syntaxes. Mais si on commence par {}, il y a quand même moins de cas particulier a expliquer. La situation est moins pire qu'avec le C++03 (bien qu'au final, un "vrai" développeur C++ devra connaitre les syntaxes C++11 et C++03)

Un beau bazar ces {} vs ().

auto x = {"qsdf", "323"}; c'est ça la plus belle des aberrations (que Meyers fustige si je ne me trompe ?).

Et il va effectivement falloir apprendre la totalité des subtilités pour peu qu'on ait à toucher des libs qui ne soient pas en C++11.

Citation:

---

Envoyé par germinolegrand

auto x = {"qsdf", "323"}; c'est ça la plus belle des aberrations (que Meyers fustige si je ne me trompe ?).

---

D'un autre côté, tu aurais voulu quoi comme type pour auto ici ?

Je crois que c'est surtout avec une valeur qui pose problème (du fait que l'on a des écritures très proches, mais qui ne donnent pas à chaque fois le même type déduit)

Code:

---

1 2 3 4

int i { 0 }; // int auto i = 0; // int auto i { 0 } // initialiser_list auto i = { 0 } // initialiser_list

---

Je me souviens plus ce que Meyers dit là dessus

moi ça me saoule ce troll qui revient sans cesse que apprendre le C c'est pas intéressant, qu'on peut apprendre le C++ sans apprendre le C d'abord,

c'est débile, et ça devrait être clair depuis le temps

moi j'ai très bien vu la différence de compréhension entre quand je programmais à 12 ans en Basic puis quand à 19 ans je suis passé au C et que j'ai programmé des fonctions de manipulation de char* et de liste chaînée, et vous aussi vous l'avez vécu donc bon : stop, fini, merci

et alors vos discussions sur "comment apprendre aux élèves le C++ version pointeur intelligents boost etc." mais c'est d'un ridicule : s'ils sont pas capables vos élèves d'apprendre eux-mêmes tout ça ben ça sert à rien d'essayer de le leur apprendre, c'est comme ça la programmation c'est mieux d'avoir 105 de QI sinon ça marche pas trop hein, alors vu les tonnes de langages d'api et tout ça, apprendre les spécificités d'un truc comme le C++11 alors qu'il y a beaucoup plus intéressant en bac+2 ou bac+3 : apprendre la cryptographie ou la programmation 3D ou même je sais pas comment marche mathematica (bon aucun prof n'est capable de l'enseigner mais ça peut changer), des trucs qui sont objectivement difficiles à apprendre tout seul et qui permettent de former l'esprit bien plus ..