Bonjour,
J'ai une question.
J'utilise c++ toutes les semaines voire toutes les jours.
 
Je vais devoir passer un test de c++ la semaine prochaine. Je flippe. C'est un peu comme pour le code de la route, je conduis mais je n'arriverai plus à passer l'exam théorique.
 
Comme d'habitude, dans les trucs qui vont tomber (peut-etre) il va encore y avoir 2-3 design patterns et les exceptions.
 
Or, une recherche rapide sur le forum montre que sur les 100 pages de sujets c++ (soit un peu moins que 5000 demandes) les questions sur les exceptions tombent 19 fois.
 
 
QUI ICI s'en sert et pourquoi faire? A quel moment lire une valeur de retour de fonction est-il insuffisant?
Merci

tu peux systématiquemetn te passer des exceptions, c'est juste un moyen plus propre, plus efficace de traiter les diverses erreurs, C'EST TOUT!

Qu'est ce qu'on peut faire quand on catch un std::bad_alloc?
Elle peut réellement être maintenue en vie l'appli?

tu peux au moins la terminer proprement le cas échéant

 
Le throw (et le mécanisme d'exception en général) te permet de propager les erreurs sur la pile d'appels, tout en continuant à utiliser le return pour autre chose qu'un code d'erreur.
De plus le catch te permet d'isoler la partie du code qui traite les erreurs (tu dois utiliser le goto en C pour faire la même chose).
 
Bref c'est mieux à tous les niveaux  

Ouais enfin le goto permet pas de remonter dans la pile d’exécution, si??? Ca marche que si le tag est dans le même scope non?
 
Sinon oui les exception c'est le pied, pas de retour a verifier (ou moins)... tu peu t’occuper de ta gestion d'erreur ou tu veux dans ton programme, c'est vraiment trés trés pratique... Par contre ça alourdi le binaire et la place qu'il prend en memoire.

 
setjmp, longjmp  

anon+1, evidemment sans l'aide du compilateur. (en C++ les objets du scope du throw sont détruits etc etc.)
les coding rules de google préconisent de ne pas utiliser les exceptions dû a un cout de maintenance difficile a maitriser.
entrendre par la, exception saybien mais en fait en industrie moins. (industrie=millions de lignes + mainteneurs qui ne connaissent pas la codebase)
moi je m'en sers extremement rarement:
eg quand je veux rajouter de la gestion d'erreur dans une fonction tres basse dans la hierarchie (fonction utilitaire) et que je veux pas me fader de changer les proto de 20 fonctions et tous les returns, et que le bon endroit pour gérer l'erreur est tres haut (proche de main())
 
sinon, en cas d'examen le premier truc a aller réviser est la C++ FAQ Lite.

 
Pas complétement d'accord. Les exceptions sont moins risquées en java/C# vu que le garbage collector nettoiera tout, mais si on ne fait pas du C++ de sagouin et qu'on utilise du RAII il ne faut pas hésiter, c'est mieux qu'un code de retour à tous les niveaux (qui ne permet d'ailleurs pas de récupérer une erreur dans un constructeur).  
Cf. Faq Lite C++ justement  
 
Google se passe aussi des RTTI, c'est un choix mais ça ne veut pas dire que les RTTI c'est mal. Idem pour les exceptions. D'autres industriels gardent les exceptions dans leurs coding rules...

 
La guideline googles est bien chez google, merci de ne pas l'utiliser a tort au vu de ses restrictions stupides.

+ avec Joel, guideline grotesque

 
En fait, c'est l'informatique que t'aimes pas, toi.
 
http://google-styleguide.googlecod [...] pguide.xml
 
Ca a le mérite d'être formalisé.
pas d'exceptions, pas de rtti, pas de c++11
Quel est le problème ...
 
Ils font pas de la recherche, ils font de la prod, il faut un langage commun à tous: à celui qui débute et qui est là en stage et au vieux barbu (qui a certainement rédigé le guide)
 

Ce guideline avait encore un sens il y a 10 ans, lorsque les compilateurs avaient du mal sur le C++ et ses nouveautées, dont justement exceptions RTTI, etc ...

A l'époque, gcc était splitté en gcc et egcs, le compilateur windows de référence était vc++ 6, aucun n'implémentait completement cette norme.

Mais de l'eau a coulé sous les ponts depuis, ces guidelines, qui avaient quand même du sens à l'époque, n'en ont maintenant plus aucune, sauf à sentir la poussère et le pré-retraité.

 
T'es gentil mais on n'est pas tous chercheurs ici, la plupart font de la prod comme tu dis  
On peut embaucher des débutants et utiliser les exceptions ou le rtti, c'est pas le choix de Google ben tant mieux pour eux hein   , si ça les arrange...  
 
Je maintiens que leur document est assez stupide sur certains points, et je ne suis pas le seul.

Nan mais ce que je voulais dire était rapport à Joel_F.
Lui peut avoir besoin de template de template de template, de chevrons imbriqués dans tous les sens et de lambdas, mais je pense que ces règles elles ont quand même été écrites dans un soucis d'avoir un vocabulaire commun minimal et à uniformiser les pratiques.
A un moment il a fallu que je fasse du C++ sans les templates et tout en statique, ça arrive.
 
Après je travaille pas DANS le compilateur. Je suis pas assez au courant de ce qui pète à la tronche de tout le monde ou pas. Si vous dites que le document est dépassé... je veux bien
 
 
Sinon j'ai pas été interrogé sur les exceptions. J'ai bien eu les design pattern, évidemment

 
Puisque ca a de l'importance pour toi, j'ai du code "en production".  En fait je suis quasiment certains que tu utilises des produits dont des parties ont ete concues avec lui...
 
Les templates nous les utilisons et pas uniquement ceux de la SL (pas autant que Joel, mais je n'hesite pas a utiliser des techniques "avancees" -- entre guillemets parce qu'une bonne partie des principes si pas tous etaient connus il y a plus de 10 ans -- quand j'en ai besoin; pas boost, parce que j'ai pas encore eu besoin de quelque chose ou reimplementer ce qu'il faut pour le cas particulier dont on a besoin n'etait pas beaucoup plus simple que de faire confirmer par les avocats que nous pouvions l'utiliser).  Les exceptions j'hesite encore moins et depuis plus longtemps.
 
Google est suffisemment gros pour que sa main gauche ne sache pas ce que fait sa main droite. Je suis loin d'etre sur que ces conventions de codage sont universellement respectees, je penche plutot pour que celles qui se trouvent sur le web proviennent d'un groupe particulier et que les autres ne se sentent en rien limites par elle (la version que j'ai lue etait caracteristique d'environnements contraints et conservateurs et en cours de transition du C vers C++).   P.e. je suis loin d'etre sur que Laurence Crawl ou Matthew Austern pour ne citer que deux employes de Google membres du comite en tiennent compte dans toutes leurs activites.
 
C++11, c'est une autre histoire.  On experimente peut-etre mais on n'utilise pas encore reellement meme si il y a des choses qu'on desirerait bien pouvoir utiliser de suite (dans notre cas, le support entre les differents compilo est trop inegal pour commencer, p.e. gcc -- un des plus avance -- qualifie toujours le sien d'experimental et globablement nous sommes bien trop conservateurs pour utiliser quelque chose d'experimental en production).

et mais cracouoin, je t'es roulé sur le pied un jour et je l'ai pas su ?

excusez moi d'avoir des opinions et de les partagés. Clairement google est tellement mieux que le reste entre leur vision étriqué de C++, leur groupe de recherches qui font du plagiat intellectuel et ne savent pas faire de recherche biblio ... mais passons.

PS: t'as le droit d'aller poser une peche, je pense que ca te fera le plus grand bien
re-PS : au cas ou y aurait des mal comprenant

Sans vouloir jouer les trouble fêtes, j'en rajoute une couche : ca me semble assez commun, même pour des plateformes relativement récentes, d'avoir des contraintes sur le compilateur utilisable et de virer les exceptions pour des questions de portabilité.
 
Après, une guideline reste ce qu'elle est, et on fait avec les contraintes qu'on a. Les exceptions ne sont pas une nécessité absolue ... Mais quand on peut s'en servir, pourquoi s'en priver ?

 
Je connaissais pas l'expression   Et le matin c'est seulement après le café    
Nan mais je sais pas, le guideline me choque pas du tout. Un chef a décidé qqch, c'est une boite privée, stout.
 
Tu dis qu'ils font du plagiat intellectuel. C'est sans rapport mais oui, peut-etre bien. Est-ce que  c'est mieux de prendre un universitaire à bac+20, le faire venir 6 mois en post-doc, lui chourrer le code qu'il a mis 3 ans à écrire, le foutre dehors, et appeler ça transfert technologique?
 
C'est hs ça sert à rien de répondre à la question    
 

 
Oui, et donc elle n'est pas aveuglement transposabel à *d'autres boites*
 

 
Paye ta SF un peu :|

Perso je ne pense pas que cette règle est une vieillerie, et surtout pas un problème de compilateur/portabilité. surtout quand on regarde la discussion qui en indique les raisons. ils disent notamment "dans du nouveau code, on abrogerai cette règle".
Je suis convaincu que les coding rules de google sont écrites par des règles de probabilité pour réduire les temps de codage et de débuggage.
même pas pour être lisible par des non éduqués au C++, même pas pour être compilable sur Ti-92, et même pas parce que c'est des vieux croutons. Mais bien pour réduire les coûts.
C'est génial pour la curiosité personelle d'utiliser des super features de ouf du C++ mais quand on pousse trop on s'apperçoit quand même souvent qu'on serait allé plus vite en faisant plus old school.
Soit parce que le debugger ne pouvait pas visualiser tel ou telle construction, ou que les messages d'erreurs du compilo nous on fait perdre 1 heure (c.f boost::mpl...) ou autre longueur... au prix de moins de type-safety par exemple. les coding rules de google poussent cette idée a bloc. voila tout

 
OK, c'est meme pas "on considere cette regle comme pertinente pour le type de code qu'on ecrit", c'est "on considere cette regle comme pertinente parce qu'on a X millions de lignes qui la respecte et il vaut mieux continuer a la respecter qu'avoir du code qui parfois la respecte et parfois ne la respecte pas et tout modifier est hors de question".

sauf que c'est contre productif. On se casse les maracas a faire evoluer un langage, de fournir des bibliothèques tierces de qualités tout ça pour que les mêmes boites qui nous poussent à faire ca disent à leur ingénieurs de faire du C-- ...
 
Un truc plus productif serait d'ameliorer la formation des gugus qui fotn du C++ pour qu'il comprennent un peu mieux.