Discussion :

[koala01]

Contrairement a des languages (et framework) comme Java ou C#, le C++ donne aux développeurs plusieurs solutions pour un même probléme.

Je comprend qu'une entreprise cherche à normaliser les techniques et l'ecriture du code source de ses applications.

On peut toujours discuter de la norme après, et la faire évoluer .

Un petit exemple parmis tant d'autres : le constructeur de copy.

J'avouerai ne pas comprendre où tu veux en venir avec ton exemple:

Le constructeur par copie est indispensable pour ce qui a sémantique de valeur, et est d'une utilité à évaluer pour ce qui a sémantique d'objet.

Et, comme il a déjà été dit, je ne suis pas sur que le passage par une macro pour assurer le fait qu'un objet n'est pas copiable soit réellement la meilleure des solutions

[gl]

De manière générale, si je peux admettre l'idée que les gens aient peur de l'incompétence de leur équipe (car il faut avouer que c'est effectivement un risque important, surtout s'il y a beaucoup de turn over), je me dis que, plutôt que de faire avec et donc effectuer un nivellement "vers le bas", il serait autrement plus intéressant (pour tout le monde) d'essayer de tirer les collaborateurs les moins compétants "vers le haut" en les incitant à parfaire leur compétances, quitte à les "surveiller" peut être d'un peu plus près

Le problème c'est que "tirer vers le haut", même si ça part d'un bon sentiment (ne voit aucun mépris dans ce terme, c'est une envie que je partage), se heurte souvent à des problèmes de coûts et de délais au moins sur le court terme et que, du fait du turn over important de certaines entreprises, il n'est pas certain que ce soit un gain à plus long terme.

En outre, ce n'est pas toujours uniquement un problème de formation (qui peut se résoudre facilement) mais parfois aussi un rejet (le terme n'est pas forcément idéal, mais je n'en vois pas de meilleur) de la part de certaines personnes, et là c'est peine perdue de vouloir tirer vers le haut.

[koala01]

Nous sommes bien d'accord sur le fait qu'il n'y a pire sourd que celui qui ne veut pas entendre

Mais, d'une certaine manière, n'est ce pas aussi une possibilité de limiter le turn over que d'essayer de faire évoluer ceux qui acceptent les remarques constructives

Il est clair qu'un type manquant de compétence à qui on dit, sans vraiment pousser la caricature, "tu es incompétant, mais trop con pour qu'on essaye de te faire évoluer" ou qu'un autre à qui l'on dit, sans pousser d'avantage la caricature : " c'est bien, tu es compétant, mais nous ne sommes pas intéressé par le fait que tu essaye de transmettre ton savoir" n'auront que très peu envie de rester...

Si, par contre, le type "un peu moins compétent" peut rentrer chez lui le soir en se disant "ce soir, je me couche moins con que je ne l'étais ce matin en me levant" ou si le type a la satisfaction d'avoir "transmis son savoir", ils se sentiront sans doute bien mieux et beaucoup moins tenté d'aller voir ailleurs si l'herbe n'est pas plus verte.

Bien sur, c'est presque une culture d'entreprise, mais, c'est une politique qui présente des avantages dés le court terme (en évitant de voir quelqu'un remettre son préavis juste à la fin de sa période d'essai)

[Klaim]

J'aurais presque tendance à demander si cela implique que la connexion internet est considérée comme systématiquement existante et de qualité ?

Je suis d'accord avec le fait que, théoriquement du moins, un fichier ne peut pas être absent sur console, mais, à coté de cela, étant donné que les consoles sont de plus en plus utilisées pour le jeu en réseau, que va-t-il arriver si, d'aventure, la connexion adsl vient à être coupée, pour une raison ou une autre?

Sur les consoles et autres systèmes embarqués (téléphones portables et autres, anciennes générations) sur lesquels j'ai pu travailler, l'API officielle de l'OS ou du Firmware fournissait de la documentation explicitant les fonctions callback à implémenter dans l'implication pour gérer les cas d'interruptions ou autres erreurs ou comportement spéciaux rapport au hardware ou a un événement hors application.

Cela dit, plus le temps avance, plus les OS de nos systèmes embarqués s'approchent de ce que l'on a sur nos postes de travail, donc il se peut que les OS plus récents (IPhoneOS4.0, Android, etc.) et les firmware des consoles du futur permettent d'utiliser les exceptions du C++ pour ce genre de cas aussi.

[benzoben]

Ce serait intéressant de savoir (de façon générale, sans donner de nom) dans quel type de boite évoluent les participants de ce thread.
Parce que personnellement je suis dans le service informatique et clairement le turn over et le besoin de gérer les (manques de) compétences sont des composantes majeurs que de telles conventions de code sont nécessaires.
Je dirais même que souvent elles n'existent même pas, donc il n'y a même pas de conscience du problème!
Alors quelles sont ces boites qui misent tout sur la compétence de leurs développeurs? Y en a encore en France?

[LittleWhite]

Je ne suis pas dans une boite en France ( ni même française ).

Nous programmons en C. Et malheureusement, nous n'avons pas de convention ( je vais l'écrire, un jour si j'ai du temps ). Heureusement, ma branche n'est pas "trop importante", mais je fais de mon mieux pour amélioré les "choses". Enfin bref ..

[nikko34]

Je suis avec la même équipe de dev d'une boite en france depuis la création de cette équipe, il y a 4 ans. Mais pas une SSII.

Des conventions de codage sont necessaires. Mais généralement ça ne concerne que de la mise en forme et du bon sens. Pas des restrictions du langage.

[JolyLoic]

Je suis chez un éditeur de logiciel. Et le turnover n'est pas très élevé. En gros, une fois la première année passée, les gens ont tendance à rester. Parmi les développeurs actuels, on a comme ancienneté (environ) :
12, 11, 10, 9, 9, 5, 1, 1.

Et oui, les technologies ont évolué, les gens ont progressé... Et appliquer des règles trop castratrices serait très mal apprécié.

[Klaim]

Je ne travaille plus actuellement dans une boite qui utilise C++ mais plutot Flash et Java. Auparavant j'ai été dans une boite de jeu vidéo pour du développement sur NDS, et avant ça j'ai été dans plusieurs boites pour du développement embarqué sur PDA et téléphones portables.

Dans la boite de jeu vidéo, il y avait beaucoup de choses a faire et les conditions faisaient qu'il y avait pas mal de liberté pour arriver au résultat escompter dans les temps.

Le meilleur exemple de boite que j'ai eu était juste avant, une boite qui produit un logiciel de navigation sur portable et pda (même sur les vieux portables, pas juste les smartphones, l'iphone n'existait pas quand j'y bossais).
Contrairement a la plupart des boites dans lesquelles j'ai été, ils tiraient plutot les développeurs vers le haut. Pour ça ils cherchaient pendant longtemps des gens qui simplement savaient utiliser leur bon sens en programmation. En quelques mois j'y ai énormément apris, bien plus que les 3 ans qui avaient précédé.
C'est dans cette boite qu'il y avait une stl-like maison. Comme dit précédemment j'avais demandé la raison d'utiliser une STL maison et la raison était principale le controle du comportement (les implémentations sur les différentes plateformes différaient dans le comportement...). Il y avait d'autres raisons dont on a déjà discuté. Je ne me souviens pas si on avait droit aux exceptions mais il me semble que c'était plus en rapport avec la plateforme visée.

Sur console par contre c'était prohibé, il suffisait de lire la doc de l'API de la console pour être convaincu (vu qu'ils expliquaient eux même pourquoi ils le déconseillaient). Etant donné la "puissance" de la machine (NDS) ça ne m'a pas parru étonnant de ne pas vouloir payer le coup de la gestion des exception sur cette plateforme. Plus que cela, les exceptions devaient de toutes façon sauter dans la version finale de l'application.
Cela dit, la STL fournie utilisais peut être les exception, je ne saurais pas dire. Tout ce que je sais c'est que dans la version "release" de cette bibliothèque, il n'y avait plus aucune vérification effectuée, pour gagner en perf.
Classique.

[GAujay]

D'après ce que je sais, il y a au moins une raison pour laquelle Google n'utilise pas les exceptions (sur Android, tout du moins).

Comme vous le savez peut-être, le NDK pour Android ne supporte pas officiellement la gestion de la STL, RTTI, et des exceptions. D'après un responsable du projet chez Google (David Turner, si mes souvenirs sont bons), ces spécificités du langage C++ ont volontairement été supprimées car, à l'époque, beaucoup trop gourmande en ressources. En effet, lors des premiers pas du projet, le compilateur utilisé alors était le version 3 (si mes souvenirs sont bons, encore une fois) de GCC. Hors, sur les plateformes mobiles notamment, la compilation des mécanismes d'exceptions étaient tout simplement très mauvaise (taille du binaire beaucoup plus importante, performances largement diminuées, etc). Depuis, la gestion des mécanismes d'exceptions est devenue quasiment "0 cost" (grâce à GCC 4), dixit le même responsable Google.

Je pense donc qu'il s'agissait avant tout d'un choix historique technique, plus que d'une réelle volonté de cadrage de ses développeurs (du moins en ce qui concerne les exceptions). On ne rigole pas avec la portabilité et les performances chez Google ! ^^

[koala01]

D'après ce que je sais, il y a au moins une raison pour laquelle Google n'utilise pas les exceptions (sur Android, tout du moins).

Comme vous le savez peut-être, le NDK pour Android ne supporte pas officiellement la gestion de la STL, RTTI, et des exceptions. D'après un responsable du projet chez Google (David Turner, si mes souvenirs sont bons), ces spécificités du langage C++ ont volontairement été supprimées car, à l'époque, beaucoup trop gourmande en ressources. En effet, lors des premiers pas du projet, le compilateur utilisé alors était le version 3 (si mes souvenirs sont bons, encore une fois) de GCC. Hors, sur les plateformes mobiles notamment, la compilation des mécanismes d'exceptions étaient tout simplement très mauvaise (taille du binaire beaucoup plus importante, performances largement diminuées, etc). Depuis, la gestion des mécanismes d'exceptions est devenue quasiment "0 cost" (grâce à GCC 4), dixit le même responsable Google.

Je pense donc qu'il s'agissait avant tout d'un choix historique technique, plus que d'une réelle volonté de cadrage de ses développeurs (du moins en ce qui concerne les exceptions). On ne rigole pas avec la portabilité et les performances chez Google ! ^^

Bienvenue sur le forum

Le fait est que, si je peux considérer comme logique d'imposer des règles plus ou moins "castratrices" quand elles ont pour but de répondre à des problèmes particuliers dus à une implémentation particulière de compilateur, je trouve pour le moins dommage de ne pas envisager leur abrogation quand on se rend compte que l'évolution du compilateur le permet, simplement parce qu'il s'agit de "règles historiques".

Admettons que les outils, le matériel et l'état de l'art de l'époque ne nous incitent pas à utiliser certains mécanismes.

Il est tout à fait logique de refuser de les utiliser, car il serait irresponsable de faire autrement.

Mais quand on se rend compte, 5, 10 ou 15 ans plus tard, que les outils, le matériel et l'état de l'art ont à ce point évolué que de nouveaux besoins ont vu le jour, peut être est-il opportun d'envisager de passer "à la version supérieure" afin de prendre les différentes évolution en compte, non

Nous en revenons toujours au même point: si, tôt ou tard, il n'était jamais question de revenir sur des décisions qui n'ont plus de raison d'être, nous en serions encore occupés à travailler sur un unique écran en ligne de commande vert sur fond noir

Je ne dis pas, loin de là, que les règles générales doivent être modifiées à tout bout de champs, mais, selon moi, il arrive un moment où un bon dépoussiérage s'avère plus que nécessaire.

Quand on remarque que la version du compilateur supporte (depuis longtemps) des mécanismes particuliers sans imposer de surcout prohibitif, que le matériel devient suffisamment performant pour amortir ce surcout et que l'état de l'art tend à rendre ces mécanismes "naturels", je crois que l'on peut dire que ce moment est arrivé

[Firwen]

En ce qui concerne le refus de l'utilisation des exceptions en C++, Google n'est pas si marginal que ça.
Trolltech/Nokia a la même doctrine pour sa librairie Qt, les principales raisons évoquées sont les problemes rencontrés en cas de bindings vers d'autres langages et les problemes de portabilité avec des devices embarqués.


Pour ma part, je dis oui aux exceptions dans un programme, non dans une bibliothèque.

[Klaim]

Je ne vois pas le problème avec une bibliothèque, au contraire. La plupart des exception que peut soulever le code d'une bibliothèque doit être intercepté en son sein c'est sur, mais certaines doivent quand même être transmises à l'extérieur si le traitement est réellement une "exception" difficile à ignorer.

[benzoben]

Le problème des exceptions (outre peut être le léger surcout de performance que cela entraine) c'est qu'il y a plusieurs façons de les gérer et qui impliquent des philosophies différentes. Pour n'en citer que quelques une:

• Catcher tôt ou laisser remonter jusqu'en haut
• Logger à chaque fois ou pas
• Quelles informations embarquer

De plus, prévoir une bonne hiérarchie d'exception pour couvrir l'ensemble des problèmes potentiels est déjà une gageure. Ou alors faire comme beaucoup, une seule exception générique MonAppException.

[dvdbly]

@Joel : les tequels lapons, c'est la première fois qu'on me la fait celle la...

C'est quoi un tequel ?

[Invité]

Je ne vois pas le problème avec une bibliothèque, au contraire. La plupart des exception que peut soulever le code d'une bibliothèque doit être intercepté en son sein c'est sur, mais certaines doivent quand même être transmises à l'extérieur si le traitement est réellement une "exception" difficile à ignorer.

Peut-être que Google veut faire des bibliothèques qui ne servent pas que depuis C++, avec le même compilo, et qui pourront aller sur de l'embarqué.

[nikko34]

Le problème des exceptions (outre peut être le léger surcout de performance que cela entraine) c'est qu'il y a plusieurs façons de les gérer et qui impliquent des philosophies différentes. Pour n'en citer que quelques une:

• Catcher tôt ou laisser remonter jusqu'en haut
• Logger à chaque fois ou pas
• Quelles informations embarquer

De plus, prévoir une bonne hiérarchie d'exception pour couvrir l'ensemble des problèmes potentiels est déjà une gageure. Ou alors faire comme beaucoup, une seule exception générique MonAppException.

C'est un faux problème. Et le léger surcout de performance n'intervient.... que si l'exception arrive. Contrairement à la vérification d'un retour de fonction qui intervient à chaque appel.

Pour la stratégie ben... ça dépend du programme et chacun fait ce qu'il veut. On catche la bonne exception au bon moment. Si on veut continuer à tourner quand il y a cette exception ou pas. Par exemple un "new" de base va te lancer une exception s'il n'y a plus de mémoire dispo. Je ne connais personne qui fasse de try-catch de std::bad_alloc à chaque new trivial.

Pour la hierarchie d'exception, ben déjà tu peux juste lancer des std::runtime_error par exemple si c'est générique. Après si tu as des exceptions bien particulière ben tu fais ta hierarchie, franchement ça revient juste à faire dériver des exceptions l'une de l'autre.

Franchement dans un programme C++ classique, pourquoi se priver? Je ne vois pas.

[koala01]

Le problème des exceptions (outre peut être le léger surcout de performance que cela entraine) c'est qu'il y a plusieurs façons de les gérer et qui impliquent des philosophies différentes. Pour n'en citer que quelques une:

• Catcher tôt ou laisser remonter jusqu'en haut
• Logger à chaque fois ou pas
• Quelles informations embarquer

De plus, prévoir une bonne hiérarchie d'exception pour couvrir l'ensemble des problèmes potentiels est déjà une gageure. Ou alors faire comme beaucoup, une seule exception générique MonAppException.

C'est un faux problème. Et le léger surcout de performance n'intervient.... que si l'exception arrive. Contrairement à la vérification d'un retour de fonction qui intervient à chaque appel.

Pour la stratégie ben... ça dépend du programme et chacun fait ce qu'il veut. On catche la bonne exception au bon moment. Si on veut continuer à tourner quand il y a cette exception ou pas. Par exemple un "new" de base va te lancer une exception s'il n'y a plus de mémoire dispo. Je ne connais personne qui fasse de try-catch de std::bad_alloc à chaque new trivial.

Pour la hierarchie d'exception, ben déjà tu peux juste lancer des std::runtime_error par exemple si c'est générique. Après si tu as des exceptions bien particulière ben tu fais ta hierarchie, franchement ça revient juste à faire dériver des exceptions l'une de l'autre.

Franchement dans un programme C++ classique, pourquoi se priver? Je ne vois pas.

Je suis totalement de l'avis de nikko...

Avec un code d'erreur, tu dois aussi choisir de le prendre en compte ou non, et de quoi faire si tu décide de le prendre en compte.

La différence qu'il y a avec les exceptions, c'est que, si tu ne récupère pas ton code d'erreur, il est perdu, et difficile de le récupérer, alors qu'avec une exception, si elle n'est pas récupérée, elle reste disponible pour les fonctions appelantes précédentes, sans courir le risque de perdre de quelconques informations de contexte.

De plus, il t'est beaucoup plus facile de compléter ta hiérarchie d'exception "au coup par coup", en définissant en cas de besoin les nouvelles exceptions sous la forme de classe imbriquée dans la classe qui risque de la lancer, que de devoir maintenir une liste de code d'erreur qui ne fera que grandir avec le temps, et qui pourra nécessiter de modifier énormément de code à chaque ajout.

[ac_wingless]

Travaillant pour des projets industriels pour lesquels nous ne sommes pas maitres d'œuvre, nous sommes exposés à autant de règles de codage. A priori, celle de Google me parait très laxiste pour une société de cette taille, et je suis un peu étonné des réactions de ce forum.

La méfiance vis-à-vis de la compétence interne (et externe, puisque souvent les règles de codage servent à fédérer des intervenants différents dans un même projet, même si ce n'est pas le sujet dans cette discussion précise) est quelque chose qui ne doit pas être sous-estimée. C'est presque trollesque de le rappeler, mais c'est vrai et vous avez tous au moins un ou deux exemples en tête: de trop nombreuses personnes ont payé de leur vie des erreurs de programmation qui auraient peut-être pu être évitées par des règles de codage conservatrices et strictement enforcées. Certes, ça veut aussi dire que la QA a foiré quelque part dans ce genre de cas. C'est bien pourquoi maintenant la QA nous met des conventions "castratrices" pour faciliter son propre boulot, et elle a bien raison, après tout il y a un budget donné pour un ensemble, le développement logiciel n'en étant qu'une partie au même titre que le firmware, hardware, QA, etc.

En particulier, les discussions concernant les exceptions peuvent être réglées en interdisant les exceptions, et donc vont typiquement être réglées ... en interdisant les exceptions. Dans un gros programme de plusieurs millions de lignes de code faisant intervenir 15-20 sociétés travaillant dans 12 fuseaux horaires, ou même dans des projets moins ambitieux, et même sans problèmes de code source historique, on ne peut tout simplement pas justifier le gain de productivité apporté par tel ou tel argument en regard ne serait-ce que du temps perdu à discuter la validité de l'argumentaire en question. Point final! Je ne dis pas que tel ou tel a raison dans cette discussion, j'ai bien évidemment ma propre opinion à ce sujet (je pense que pour une équipe stable, les exceptions apportent un gain de productivité significatif par rapport aux méthodes de propagation d'erreurs), mais je la ferme dans les téléconférences passant en revue les conditions d'exécution du contrat. Bien sûr, comme d'hab, pas d'exceptions ou de RTTI, boost réduit à 3 fichiers, blablabla habituel. OK, où je signe? Parce des fois, j'ai même pas droit aux templates ou aux fonctions virtuelles...

Même dans son périmètre (donc indépendamment de son contenu), la convention Google est très laxiste. En particulier, rien n'est figé sur des points aussi variés et importants que le multitâche, l'historique des fichiers sources, les protocoles de test d'unité, les invariants, les ABI dans les architectures matérielles mixtes, la politique de gestion des latences matérielles, etc. Ceci dit, peut-être y a-t-il d'autres documents pour ces points, j'avoue ne pas avoir regardé.

En conclusion, si on se rappelle que plus de 90% des microprocesseurs sont embarqués, que sur ceux ci, pratiquement aucun ne dispose d'un compilateur C++ avancé, on s'aperçoit que développer sous VC++ 10 / Windows 7 est d'un luxe tellement hallucinant qu'on peut même carrément se permettre d'ergoter sur des surcouts de performances en cas de déclenchement d'exception! Nous nous vautrons dans le bonheur total, quoi. En tout cas, moi j'adorerais avoir droit aux conventions Google pour ne serait-ce qu'un quart de mes projets. Ça me ferait des vacances

[benzoben]

Je suis tout a fait d'accord.
Je ne suis pas du tout contre les exceptions bien au contraire. Mais c'est vrai qu'à partir d'une certaine taille de projet, il faut malheureusement un peu "museler" les individualités pour le bien de tous. Car passer du temps à debugger le bout de code optimisé aux petits oignons et dont seul l'auteur a su ce qu'il voulait faire, eh bien, des fois c'est pas possible.