# Le club des professionnels en informatique > Actualits >  Quel est pour vous le dfaut le plus gnant du C++ ? Un dveloppeur chevronn fait la liste ses faiblesses

## Idelways

*Quel est pour vous le dfaut le plus gnant du C++ ?*
*Un dveloppeur chevronn fait la liste des faiblesses de son langage prfr*


Les critiques qui mettent en relief les dfauts des langages de programmations viennent en gnral de la part des dveloppeurs qui utilisent des technologies autres, voir concurrentes.

C'est pour cette raison que la critique qu'on vous propose pour ce dbat nous semble intressante, elle est signe du pseudo  razvanpetru  derrire lequel se cache un dveloppeur C++ aux 10 annes d'exprience.


L'article prsente les dfauts en deux parties. Parmi ceux qui gnent l'auteur, on trouve: 

 ::fleche::  Le temps de compilation et la gestion des dpendances
 ::fleche::  La bibliothque standard, qu'il juge rduite.
 ::fleche::  Le manque de rflexivit et la dduction des types
 ::fleche::  Les messages d'erreurs des templates
 ::fleche::  Le support de l'internationalisation sur la bibliothque standard

Parmi les dfauts souvent points du doigt et qui ne le gnent pas, il cite :

 ::fleche::  La gestion et la corruption de la mmoire
 ::fleche::  La gestion du multitche
 ::fleche::  Le support des chaines de caractres
 ::fleche::  Les exceptions
 ::fleche::  STL, Boost et les templates en gnral

Mais que l'on ne s'y trompe pas. Pour  razvanpetru , il s'agit juste du prix  payer, pas de dfauts qui dcrdibiliseraient le C++.

Car comme dit le proverbe :  personne n'est parfait .

Et pour vous, quel est le dfaut le plus gnant du C++ ?

*Source :* lire l'article: What's wrong with C++


*Lire aussi :*

 ::fleche::  Le moc (meta-object compiler) a-t-il toujours une raison d'exister, maintenant que les compilateurs ont volu ? 
 ::fleche::  Microsoft dcouvre une faille dans MFC qui pourrait aboutir  des dpassements de tampon 
 ::fleche::  Microsoft Visual C++ 2010 Express : Tlchargement, installation et configuration par 3DArchi 


Les rubriques (actu, forums, tutos) de Dveloppez :

 ::fleche::  C++ 
 ::fleche::  Qt 
 ::fleche::  Langages 




*En collaboration avec Gordon Fowler*

----------


## stardeath

ce qui me gne le plus dans le c++, je l'ai soulign dans un autre topic, c'est le manque de cohrence entre toutes les briques;

du genre la nomenclature comme dans setw, setprecision, des fois en abrg, des fois non, difficile de comprendre pourquoi mais ce n'est le plus dramatique.

un autre que je trouve plus problmatique s'admire sur la signature du main standard : int main(int argc, char **argv) et ses drivs avec le char* argv[], on a une bibliothque standard avec quand mme pas mal de choses MAIS pour l'entre d'un programme on rgresse du c++ vers le c; pour rester dans le c++ quelque chose du style de int main(vector<string> args) aurait t plus appropri selon moi.

----------


## saad.hessane

Deux dfaut :
Les gens qui enseignent/pratiquent le C++ comme du CLes diffrentes implmentations des compilateurs ...

----------


## Oussapik

Le manque de rflexivitLes messages d'erreurs parfois trop verbeux, on obtient pas l'information que l'on souhaite rapidement je trouveLa bibliothque standard trop pauvreSur une note plus lgre : ce qui me gne c'est qu'il ne soit pas plus utilis  ::):

----------


## Neko

J'en pointerais un beaucoup plus simple: l'illisibilit...

----------


## Jbx 2.0b

Pas d'diteur aussi puissant qu'on peut en trouver dans le monde Java par exemple, donc on se retrouve  faire normment de copier-coller et  retaper beaucoup de chose ( dj rien que les doublons .h/.cpp, limite a donne parfois envie de faire que de l'inline...).

----------


## metagoto

- les carts et omissions des diffrents compilos par rapport au standard
- pas d'ABI standard
- preprocesseur trop limit/archaque
- grammaire trs complexe (difficile  parser pour les IDE etc)

----------


## Invit

Pour :
-Rapidit d'excution
-interface avec l'os/hardware sans intermdiaire permettant de bypasser tous les automatismes
-Capacit  tout grer de multiples manires
-Possibilits d'optimisation hallucinantes
-Possibilit de faire du C (vitesse, types natifs, portabilit)

Contre :
-Redondance des dclarations
-Long  programmer,  dbugger
-Risque de crash systme
-Lisibilit alatoire (dpendant de tierces parties ingales)
-Syntaxe objet bouriffante, complique 
-Hritage multiple, surcharge oprateurs peuvent rendre un code vraiment nigmatique
 -> Record du code tordu partag avec les expressions rgulires kilomtrique de perl !

----------


## psychadelic

C'est marrant, j'ai pas l'hritage multiple dans la liste..

Pourtant c'est une "fonctionnalit" qu'on vite avec soin dans "les autres nouveaux langages objet" : Java, C#...

----------


## laclac

Le temps dveloppement !

Les stats montrent que pour coder la mme chose le C++ n'est pas super bien plac en temps de codage.
Le java par exemple est mieux de ce point de vue !

----------


## S(.)B

Ah je suis soulag de voir que je ne suis pas le seul  reprocher  ce langage les inconvnients cits plus haut !
Venant de la programmation objet avec le langage Java je m'accusais souvent de critiquer certaines facettes du C++ parce que je suis pro-Java, mais de voir que je ne suis pas seul, je me dis que le problme vient peut-tre pas de moi !  ::mrgreen:: 

Pour moi les inconvnients :
- temps de dveloppement lev (aprs je suis peut-tre pas bon en C++ et je n'utilise peut-tre pas les bonnes API)
- librairie standard trs (trop ?) rduite
- des fois d'une illisibilit dconcertante
- manque de conventions de nommage (a je ne sais pas trop  qui/quoi il faut le reprocher)
- le couple .h / .cpp qui arrive  me rendre dingue ! (pourquoi pas une gestion " la Java" ?)
- et encore beaucoup mais je ne veux pas passer pour un rabat-joie...

----------


## alexis b

> Possibilit de faire du C (vitesse, types natifs, portabilit)


Utiliser les types natifs (et faire des algorithmes de faon ultra optimise) c'est tout  fait dans l'ide du c++ (pas seulement du c) et cela ne va aucunement  l'encontre de l'esprit du langage.

----------


## Oussapik

> En ce qui me concerne, je fais du vrai c++ (c'est  dire de la programmation oriente objet and all), mais je suis galement trs bon en c  .
> 
> 
> Utiliser les types natifs (et faire des algorithmes de faon ultra optimise) c'est tout  fait dans l'ide du c++ (pas seulement du c) et cela ne va aucunement  l'encontre de l'esprit du langage.


La possibilit de faire du C n'a pas t voque comme point ngatif, au contraire. Nous sommes donc d'accord sur ce point  :;):

----------


## Luc Hermitte

> C'est marrant, j'ai pas l'hritage multiple dans la liste..
> 
> Pourtant c'est une "fonctionnalit" qu'on vite avec soin dans "les autres nouveaux langages objet" : Java, C#...


Il est ncessaire  la prog par contrat native.
Et quand on voit la source (*) des problmes avec l'hritage multiple, c'est limite l'hritage qu'il faudrait interdire....
De plus tous les "nouveaux" langages  objets ne l'vitent pas, cf ruby qui je trouve a un modle plus propre que les langages auxquels tu pensais.

(*) La comprhension mme du LSP -- qui n'a rien de propre au C++.


Accessoirement, l'article original est plus intressant que le rsum fort trollesque qui initie ce fil.

Et +1  confusion entre C++ et "truc qui ressemble  du C" qui gangrne la pratique, et l'enseignement.

----------


## jbb2811

Je rajouterais :
- la portabilit toute relative.
- le ddain de la STL par les librairies graphiques ( qui chacune redfinissent les types de bases, chanes, listes, tableaux...)
- la complexit  intgrer des modules dvelopps par des moyens diffrents

JB

----------


## pseudocode

> Et pour vous, quel est le dfaut le plus gnant du C++ ?


Le fait qu'on est jamais sr de ce que fait une ligne de code... merci les #define, la surcharge d'oprateur, les transtypages implicites, ...

----------


## Invit

> La possibilit de faire du C n'a pas t voque comme point ngatif, au contraire. Nous sommes donc d'accord sur ce point


Oui, je l'ai mis dans le pour (avantages)
Ok pour les types natifs. 
Le fait que C++ soit historiquement un surensemble de C cache des subtilits notamment dans la gestion des strings. Elles sont la force et la faiblesse du C mais beaucoup plus rapides avec pointeur (malloc/free) que tous les autres systmes. Par contre la portabilit d'un algo C utilisant des char* est mauvaise sur un environnement new/delete, avec ou sans garbage collection

Le C a pour lui une omniprsence dans l'embarqu, traitement de signal, ...  partout ou les perfs sont cruciales en fait.. il peut aussi tourner sur un os quasi-inexistant. C++ le pourrait aussi mais c'est plus compliqu, dans l'embarqu , C reste la rference

----------


## befalimpertinent

> Et pour vous, quel est le dfaut le plus gnant du C++ ?


L'absence (mais c'est sur le point d'voluer, cf C++0.X) des fermetures

----------


## Firwen

Je prcise avant tout que C++ est de loin mon langage favori pour tout un tas de raisons trop longues  numres. :8-): 


Mais c'est vrai qu'il a des dfauts, parmi lesquels en vrac :

- Pas de porte parentale dans les nested class / struct / functor
- Support d'unicode bancale de base.
- Typage sur les retours constants pas toujours tops suivant les compilos
- templates pas assez standariss qui dpendent trop du compilo
- STL trop pauvre, qui fait peur aux dbutants et qui force  utiliser boost ou autre.
-  Une dition des liens dgeulasses et pas standardiss  (contrairement   C) ce qui complique pas mal les bindings vers d'autres langages et la creation de libs.
- pas de gestion des co-routines sans libs externes.
-  Pas d'internationalisation de base.
-  La rsolution des dpandences trop calque sur le C.
-  Dclaration trop verbeuses
- Les systmes de signaux / callback devraient tre intgrs au langage au lieu de dpendre du moc, des templates, des preprocesseurs ou de tout autre systme douteux.

----------


## saad.hessane

+1 pour la gestion de l'Unicode et pour le couple .h/.cpp un peu lourd

----------


## vg-matrix

> Deux dfaut :
> Les gens qui enseignent/pratiquent le C++ comme du CLes diffrentes implmentations des compilateurs ...


Ce sont des dfauts qui me gnent normment !

----------


## Invit

C'est marrant car je suis hyper d'accord avec les rserves sur l'unicode mais quand j'ai commenc ce job, l'unicode n'existait pas et l'venementiel n'tait q'un futur caprice d'diteur d'os acharn sur sa concurrence. Du coup ces rserves me seraient jamais venues  l'ide mme si C# volue dans une autre galaxie, je reste un "vieux" qui lanait sa makefile en ligne de commande sur cross-compilateurs ..

Reste que la ligne des compilos C et descendants C++ a gard une authenticit d'un autre age que vous percevez comme des dfauts mais je ne peux pas m'empcher de penser que faire une telle infidlit  Kernigahn et Ritchie serait dnatur C++ et son papa unix

Ce ne serait plus du C et donc il faudrait presque changer son nom, dj que C++ tait implment sous forme de prprocesseur  l'origine...  

En me mettant  votre place,

Est-ce que le pire dfaut du C++ ne serait pas cette parente avec K&R justement ?

a semble compltement dpass alors que la syntaxe du C a t adopte par une bonne douzaine de languages de premier plan...  

A mon avis , C++ est arriv un peu trop tt dans la gnalogie des langages objets.  La volont de prserver  tout crin la logique du C est son pch originel. (bibliothque arborescente, diteur de liens statique, ...)

Seulement voil : ces deux languages sont rests monopolistiques dans les systmes d'exploitation ...   Changer C ou C++ comme vous le dites, c'est renoncer  compiler Windows avec !!!!!!    
Big problem !  
C'est comme scier sa branche ...

Changer C++ dans ce sens me semble simplement impossible avant des dcennies..........................  supposer qu'un fou dcide d'crire un nouvel OS dans un autre language ...   Y-A-T-IL DES CANDIDATS ?

----------


## Luc Hermitte

> * Les gens qui enseignent/pratiquent le C++ comme du C
>     * Les diffrentes implmentations des compilateurs ...


Autant je suis on ne peut plus d'accord sur le premier, autant sur le second, ce n'est pas un vritable problme.
Les problmes de compatibilit des compilos surgissent surtout quand on commence  faire de la voltige  coup de templates. Et du coup ... on se retrouve  crire  la place le mme genre de code que celui que l'on aurait crit avec les autres langages de la mme famille. (non parce que ... les extrieurs qui nous regardent rler, ne percuteront jamais que c'est relativement  des fonctionnalits dont ils ne peuvent mme pas rver avec leur langage mainstream)

Un problme connexe, mais plus ennuyeux  mon gout : l'inertie relative aux montes de versions. Dans nos processus industriels, on ne peut pas monter de version quand cela nous chante et comme cela nous chante. Du coup on se retrouve vite bloqu avec des outils (compilos, libs, OS, cartes graphiques) dsuets et limits quand on les compare  l'tat de l'art. Mais cela n'est pas propre au C++. C'est valable avec les autres langages qui voluent (et avec les autres fameworks galement).

----------


## pseudocode

> Est-ce que le pire dfaut du C++ ne serait pas cette parente avec K&R justement ?


C'est pas trop la parent, c'est surtout le mlange.  Pouvoir "caster" un pointeur sur objet C++ comme on caste un pointeur sur structure C, c'est en soi dj un problme.  ::?:

----------


## kain_tn

Peut-tre un des dfauts les plus rebutants pour les dbutants:
les messages d'erreurs incomprhensibles ds lors que l'on utilise la STL ou de la mta-programmation...

----------


## Luc Hermitte

> Peut-tre un des dfauts les plus rebutants pour les dbutants:
> les messages d'erreurs incomprhensibles ds lors que l'on utilise la STL ou de la mta-programmation...


Pour moi, le vrai problme est le manque d'initiation correcte -> stlfilt ! (en plus, le gars qui avait crit l'article en avait parl...)

----------


## Invit

> C'est pas trop la parent, c'est surtout le mlange.  Pouvoir "caster" un pointeur sur objet C++ comme on caste un pointeur sur structure C, c'est en soi dj un problme.


Plus je tourne cette question plus son caractre absurde me semble impossible

Tous les kernels systmes sont en C, tous les runtimes venementiels sont en C, tous les langages de haut niveau (PHP, Java, ..) sont crits en C !

Implmenter les fonctions de ces langages dans le C(++) me semble un court-circuit dans l'espace-temps, une porte des toiles, un truc qui changerait l'eau en rayon cosmique ou plus srieusement, remet en cause le principe de causalit ce qui rendrait l'univers improbable et risquerait de plonger l'humanit dans une boucle infinie

Il faut quand mme bien crire tous ces trucs avec quelque chose !

L'assembleur, oui mais on a dit depuis 45ans que le C tait mieux...  l'crire dans un language crit en C serait limite impossible (quoique...)et tous les systmes crits en Pascal ont t entirement rcrits en C (++ ou non)

Au bout du compte : C++ restera une extension de C base sur les mmes principes et tant qu'on n'aura pas invent de processeur quantique qui se programme en vlapuk ,   a ne changera pas 

*SAUF SI*

Les diteurs de compilateurs dcident de crer un "C for Applications", diffrent du C for System, qui lui vient avec l'OS et permet de le recompiler (sous unix) ou vient de soft qui n'autorise pas la recompilation de windows mais la cration de drivers, services...

Au final , on se retrouve avec 2 C diffrents dont l'un possde son C++ driv et l'autre, un C++ entirement rcrit. Dans ce cas , il devient possible de grer l'Unicode, les ressources, supprimer les wizards et autres gnrateurs de code au profit de rfrences sur des bibliothques. Un peu comme C# mais sans framework ni garbage collection...

Mais un tel langage mriterait-il de s'appeler C++ ?
Microsoft ne le fera jamais, Gcc non plus....   Ceux d'entre vous qui ne comprennent pas o je veux en venir auront plus de succs en tudiant Java ou C# , langages trs voisins, trs performants, dix fois plus faciles  apprendre et ouvrant sur d'excellentes carrires!

Enfin , on peut faire comme Sarah Palin, affirmer que l'homme et le dinosaure ont vcu en harmonie sur terre il y a 12000 ans, ne pas penser, juste coder...

----------


## Sababo

Comme certaines personnes ici, je suis un grand adepte du C, et j'ai aussi pas mal touch au C++.

Je suis tout  fait d'accord avec pas mal des "faiblesses" du C++, comme les messages d'erreur quand on utilise la mta-programmation ...

Mais il y a un point qui est cit qui pour moi et un norme avantage : sparation entre la dclaration et l'implmentation (.h / .cpp).

Cette organisation permet de savoir rapidement comme utiliser du code sans forcement avoir  tout lire. Je dveloppe une bibliothque, et quand je veux l'utiliser, j'en ai rien  faire de comment elle fonctionne, je veux juste savoir ce qu'elle fait et comme lui "parler". C'est dans le mme esprit que le paterne MVC.

Aprs, c'est vrai que a cre de la redondance d'information.

----------


## doublex

C'est trs personnel, mais pour moi, le plus grand dfaut du C++, c'est sa proximit avec le Java. Je n'ai pas voulu mlanger les deux. 
Un peu comme ne pas apprendre l'Italien quand on sait l'Espagnol.

----------


## Invit

> C'est trs personnel, mais pour moi, le plus grand dfaut du C++, c'est sa proximit avec le Java. Je n'ai pas voulu mlanger les deux. 
> Un peu comme ne pas apprendre l'Italien quand on sait l'Espagnol.


C++ est arriv au moins 5 ans avant java. Ces deux languages n'ont pas la mme faon de compiler ni de fonctionner. La plupart les outils java (notamment la VM)  sont crits en C++

C++ est une bible, java un prtre.

Java est le language  connaitre si vous ne voulez pas "entrer dans les ordres" et y consacrer votre vie.   

Concrtement, la matrise de C++ rclame beaucoup plus d'efforts et eu gard  ce qui est crit plus haut, a devrait empirer !

----------


## saad.hessane

> ... Mais il y a un point qui est cit qui pour moi et un norme avantage : sparation entre la dclaration et l'implmentation (.h / .cpp).
> 
> Cette organisation permet de savoir rapidement comme utiliser du code sans forcment avoir  tout lire. Je dveloppe une bibliothque, et quand je veux l'utiliser, j'en ai rien  faire de comment elle fonctionne, je veux juste savoir ce qu'elle fait et comme lui "parler". C'est dans le mme esprit que le paterne MVC.
> 
> Aprs, ces vrais que a cre de la redondance d'information.


La meilleure faon de savoir comment utiliser un code est de lire la documentation associ.
Quand tu utilises une fonctionnalit de Qt par exemple, tu ne vas pas t'amuser  chercher le .h correspondant  la classe. Un rapide coup d'il sur la doc et tu as tout ce dont tu as besoin. En Java pareil avec la Javadoc.
Et donc je ritre que la sparation du .h et du .c est une complexit en plus pour rien (ou si vous voulez pour une chose que l'on peut faire autrement et proprement).

----------


## Invit

En repensant  ce topic , j'ai t saisi d'une question : est-ce que ceux qui enseignent le C++ expliquent sa particularit de langage systme. Je suis all sur Wikipaedia france et english http://en.wikipedia.org/wiki/C%2B%2B

Et je lis  peu prs la mme chose qu'ici  savoir que C/C++ est juste un langage comme les autres en plus compliqu. Il n'en est rien messieurs-dames!
Mme si wiki n'aborde pas ce point (c'est donc un scoop) il faut savoir que l'immense majorit du logiciel grand public mondial est crit en C/C++ , en fait un mlange de C et de C++. C'est le cas de Windows, IE, MSN, Office (tous les logiciels) VisualStudio, Notepad, Firefox, Chrome, Photoshop, The Gimp, .....etc....
Bien sr tout Linux est en C/C++, tout ce qui tourne sur iPhone, Ipad (y compris applications) MacOSX est une version modifie de Linux..

Mais aussi :
Tous les compilateurs C/C++, Les languages comme VBA, Javascript, la machine virtuelle Java. Egalement tous les jeux video (ceux qui s'installent via setup) 
Tout a et 99.99% du reste est crit en C/C++ , gnralement aux tats unis !

Voil pour le scoop

Maintenant le sujet du topic "que reprocher  c++" prendra peut-tre une autre dimension...

----------


## saad.hessane

> ...
> Mme si wiki n'aborde pas ce point (c'est donc un scoop) il faut savoir que l'immense majorit du logiciel grand public mondial est crit en C/C++ , en fait un mlange de C et de C++. C'est le cas de Windows, IE, MSN, Office (tous les logiciels) VisualStudio, Notepad, Firefox, Chrome, Photoshop, The Gimp, .....etc....
> Bien sr tout Linux est en C/C++, tout ce qui tourne sur iPhone, Ipad (y compris applications) MacOSX est une version modifie de Linux..
> 
> Mais aussi :
> Tous les compilateurs C/C++, Les langages comme VBA, Javascript, la machine virtuelle Java. Egalement tous les jeux video (ceux qui s'installent via setup) 
> Tout a et 99.99% du reste est crit en C/C++ , gnralement aux tats unis !
> 
> Voil pour le scoop
> ...


Oulla faut pas forcer  ::D: .
L'immense majorit du logiciel mondial ??? Les statistiques tu les sors d'o?
Un noyau systme est forcment crit dans un langage systme (C/C++). Mais les logiciels qui tournent dessus pas forcment. Beaucoup de .NET, pour coder office, msn, visualstudio et windows mme. Beaucoup de Java pour coder les jeux vidos pour plateformes portables. Les jeux de la Xbox peuvent tre cod en C# (avec XNA).
MacOSX n'est pas une version modifi de Linux, mais d'Unix. Mme pas une version modifie, mais un descendant qui aujourd'hui n'a plus grand chose  voir avec.
Tout Linux n'est pas en C/C++. Le noyau est en C. Mais il y a beaucoup de Java, de Python, et mme de .NET maintenant.

----------


## pseudocode

> Les diteurs de compilateurs dcident de crer un "C for Applications", diffrent du C for System, qui lui vient avec l'OS et permet de le recompiler (sous unix) ou vient de soft qui n'autorise pas la recompilation de windows mais la cration de drivers, services...


Je ne pense pas que l'volution vienne des diteurs de compilo qui, aprs tout, sont l pour rpondre  la demande des dveloppeurs. S'il y a volution, elle viendra surement de la communaut, ou plutt DES communautS de dveloppeurs.

Comme tu les dis, le C++ est utilis par beaucoup de monde, pour beaucoup de choses et sur beaucoup de config diffrentes. Dj, on peut voir ici et l des gens prechant pour leur paroisse du C++ : la mtaprog pour certains, la gestion mmoire pour d'autres, la localisation, le fonctionnel, etc.

Si le langage (et les compilos) acceptent joyeusement le mlange des styles de programmations, il n'en va pas de mme de ces communauts (et de l'esprit humain en gnral). Aussi il me paraitrait logique que les principaux domaines d'utilisation du C++ soient rgules par des "bonnes pratiques", qui conduiraient finalement  des rgles strictes de codage... rgles qui seraient vrifies par le compilateur, donnant ainsi naissance a des sous-dialectes du C++.

Oui, je me doute que beaucoup vont s'crier que a bafoue leur droit fondamental  faire du code C++. Pourtant j'aimerai bien un monde o les browser web seraient cods en C++/nobufferoverflow, variante du C++ bannissant le char* et le strcpy.  ::D:

----------


## djouk

Hritage multiple

----------


## Invit

Au risque de montrer que je suis un vieil ours (alors que je le cache en gnral) Il me semble que C++ est l'volution "la moins rate possible" du C vers l'objet que l'industrie ait russi  produire.

L'imbrication du C et de l'industrie du logiciel est trop troite pour permettre  la fois une volution et une "compatibilit ascendante".Or sans cette dernire, le nom "C++" n'est pas lgitime.

Pour ce qui est du "droit des communauts C++" , je ralise que c'est le volume de logiciel en C produit par un petit nombre de compilateurs qui rend cette question bizarre.  Plusieurs millions d'annes/homme de travail constituent le gnie logiciel en C++ alors que .net n'existe que depuis 2001  peu prs. 

On a vu beaucoup de nouveaux langages arriver et Google continue  nous en pondre de nouveaux, mais l je suis du cot de Steve Jobs : le vrai logiciel payant en C sur l'app store, le reste est gratuit sur internet !  fin de la rcr !

Si vous saviez le nombre de vies humaines qui se sont appuyes sur C/C++ pour produire de l'intelligence numrique...  C'est vrai qu'un jour les choses changeront, mais pour l'instant , l'organe vital du logiciel depuis les annes 50 est le C/C++ , le Basic a plus ou moins inspir les langages  garbage collection.

Au final , cette discussion m'a fait prendre 20 ans, je me sens affreusement vieux

----------


## Oussapik

> il faut savoir que l'immense majorit du logiciel grand public mondial est crit en C/C++ , en fait un mlange de C et de C++. 
> [...]
> Tout a et 99.99% du reste est crit en C/C++ , gnralement aux tats unis !
> 
> Voil pour le scoop


Tu peux nous citer tes sources s'il te plait ? a me parait assez abrant ce que tu affirmes.

Mme si la programmation systme est souvent associe au C/C++, je ne pense pas que le terme "immense majorit" soit appropri ici. Comme l'a soulign ilys05, d'autres langages sont utiliss en plus d'un langage systme dans le "logiciel grand public mondial".

----------


## pseudocode

> Au risque de montrer que je suis un vieil ours (alors que je le cache en gnral) Il me semble que C++ est l'volution "la moins rate possible" du C vers l'objet que l'industrie ait russi  produire.
> 
> L'imbrication du C et de l'industrie du logiciel est trop troite pour permettre  la fois une volution et une "compatibilit ascendante".Or sans cette dernire, le nom "C++" n'est pas lgitime.


Hum... Pour moi ca aurait t "le moins mal possible" si le C++ avait proscrit l'criture de code "faon C". Aujourd'hui le terme C++ est systmatiquement accol au terme C, ce qui entretient le flou entre les deux langages. D'ailleurs comme ca a t dit ici c'est un problme lors de l'apprentissage du langage : en pratique, on est oblig d'apprendre le C si on veut coder en C++. Non pas que c'est "obligatoire", mais dans les faits (tutos, sources, librairies) les deux langages sont mls.

----------


## benzoben

Je ne suis pas un grand expert de c++ mais je suis d'accord avec ce qui a t dit avant.
Personnellement, ce que je reprocherais  C++ n'est pas tant le langage en lui mme que la documentation qui l'accompagne.
Faisant beaucoup de Java, je trouve que l'apport de la Javadoc a t norme et peut tre le fait que le langage soit sous la responsabilit d'un principal acteur (Sun) a permis de centraliser les ressources. Si je cherche une info, je vais chez Su... Oracle et voila (j'exagre un peu). De plus, la version du langage est clairement tablie. Si je consulte une doc, je sais que c'est pour la 1.4 ou la 1.5.
En fait peut tre que le problme de C++ c'est le trop grand nombre d'acteur (ce qui a dj t dit) qui ont particip  son volution.

----------


## MadScratchy

Sa syntaxe.

----------


## jpouly

Le temps de dveloppement et la complexit de mise en uvre d'une architecture modulaire (pourtant trs simple en java et c#).

Trop  de possibilits offertes aux dveloppeurs de faire n'importe quoi (ex : les diffrents type de chaines de caractres).

Une lecture trop complexe pour les non-initis.

Cela dit, le c++ a beaucoup d'avantages en termes de dploiement, de rapidit du code, de paralllisme, et de choix d'architecture, par rapport aux langages "plus" volus.

----------


## zenetcalme

Bonjour,

n'ayant pas fait beaucoup d'autre langage, je ne me permets pas de donner un avis!

par contre, je n'arrive pas  comprendre l'argument :



> complexit de mise en uvre d'une architecture modulaire (pourtant trs simple en java et c#)


Pour moi, une des diffrences principale entre le C++ et les 2 autres langages cites est le garbage collector!

Pourriez-vous m'clairer ou approfondir l'argument?

----------


## lequebecois79

> Bonjour,
> 
> n'ayant pas fait beaucoup d'autre langage, je ne me permets pas de donner un avis!
> 
> Par contre, je n'arrive pas  comprendre l'argument :
> 
> 
> pour moi, une des diffrences principal entre le C++ et les 2 autres langages cites est le garbage collector!
> 
> Pourriez-vous m'clairer ou approfondir l'argument?


Tu sais que des garbage collector existe aussi en C++?

----------


## pseudocode

> tu sais que des garbage collector existe aussi en C++?


C'est le problme et l'avantage du C++ : tout existe... mais personne n'utilise la mme chose.  ::(:

----------


## Luc Hermitte

> tu sais que des garbage collectors existent aussi en C++?


Malheureux, tu n'imagines pas. Les pointeurs doivent toujours tous tre grs  la main en C/C++. Toujours!

PS: lien rajout
PPS: (pɹɐb un,p snןd  ʇǝ)  uıǝɥ 'zǝʌɐs snoʌ 'ǝnbıuoɹı ʇsǝ,ɔ

----------


## divxdede

Bonjour,

J'ai une experience de quelques annes en C, puis C++ pour finir sur Java.

Le C tait pour moi un trs bon langage, certes avec des dfauts.
A l'inverse C++, m'a beaucoup du et ce pour plusieurs raisons:
   - Mixit entre C et C++ comme dja beaucoup soulign ici
   - Surcharge d'oprateur : Au dbut c'est magique, on adore... mais on adore pour soit !!! quand on se reprend un code source o la surcharge d'oprateur a t utilise  profusion, a devient compltement illisible. Avec du recul, c'est un mcanisme  viter en POO mme si c'est tentant (c'est un peu le champ de la sirne...)
   - Pour moi, le pire dans tout a, concerne le *polymorphisme* dsactiv par dfaut (faut dclarer explicitement les mthodes polymorphes), ce qui va  l'encontre mme de la POO...

Pour le reste, il hrite quelques inconfortabilit du C, la compilation et l'dition de lien peuvent vite devenir galre quand on a 10000 libs et qu'on veut mettre en place des scripts de compilation multi-plateforme (voire de cross-compil).

Bref, pour moi C++ ne vaut pas la star qu'est son grand pre (C).

----------


## jbb2811

> Tout a et 99.99% du reste est crit en C/C++ ...
> Voil pour le scoop


Pour ce qui est du mac ( et donc iphone ...) il me semble que c'est plutt de l'objective C non?

Pour tout ce qui est WEB, je pense qu'on a plus de Java/php/c# ... que de C/C++ ( il doit plus en rester beaucoup  faire du CGI ..), et a je pense que a commence  reprsenter un gros pourcentage des dveloppements actuels.

En fait on pourrait se passer de C++ : on peut le replacer par du Java/c# dans la plupart des cas, sauf l o la performance est primordiale ( embarqu, noyaux des OS) mais dans ce cas le C est souvent utilis.

Le seul avantage qu'il lui reste, c'est qu'il est l'un des rares langages objets  gnrer du code natif.

Sinon un autre inconvnient du C++ est sa trs faible volutivit compar  des langages plus 'vivants' comme Java ou c#. ( mais a peut tre considr comme un avantage)...

JB

----------


## zenetcalme

Effectivement, je ne savais pas qu'on pouvait avoir aussi un garbage collector en C++.
mais bon, du coup, je comprends encore moins la diffrence entre le C++ Java C# etc...

une architecture logicielle est quasi indpendante du langage de prog utilis non?

----------


## Luc Hermitte

> a- Surcharge d'oprateur : Au dbut c'est magique, on adore... mais on adore pour soit !!! quand on se reprends un code source o la surcharge d'oprateur  t utilise  profusion, ca devient compltement illisible. Avec du recul, c'est un mcanisme  viter en POO mme si c'est tentant (c'est un peu le champ de la sirne...)
> 
> 
> b- Pour moi, le pire dans tout ca, concerne le *polymorphisme* dsactiv par dfaut (faut dclarer explicitement les mthodes polymorphes), ce qui va  l'encontre mme de la POO...


a- Parfois j'ai l'impression que les gens critiquent les vlos parce qu'ils ne sont pas adapts aux escaliers et que du coup il faudrait toujours se balader  pieds.
Oui, il y a aura toujours des garnements qui utiliseront de travers ce qu'ont leur met  disposition. Reste que c'est bien plus agrable  utiliser que les interfaces SAXPYiennes des BLAS, ou mme de ce que l'on trouvera en Java.

b- Bien au contraire. Je me permets de copier-coller de la prose que j'avais crite pour un doc de qualit:




> *3.7.8. Les fonctions membres d'une classe ne seront pas dclares virtuelles par dfaut. Elles le seront uniquement si cette fonction correspond  un point de variation prvu lors de la conception de classe.*
> 
> Une cole tend  dfinir toutes les fonctions en virtuel :  _mettons la fonction en virtuel, quelqu'un pourrait vouloir la supplanter_ . Seulement...
> 
> Si une fonction ne correspond pas  un point de variation [Coplien1998] prvu lors de la conception, il reste peu probable que l'on puisse tendre le systme simplement parce que la fonction tait virtuelle. Bien souvent, rajouter correctement un point de variation non initialement prvu demande un refactoring non trivial du code, c'est--dire bien plus qu'ajouter un simple "virtual".
> 
> Bien sr, plus les fonctions d'une classe respectent la rgle Section 3.1.3,  _Une fonction doit faire une chose, et doit le faire bien. Ainsi, le nombre de lignes d'instructions efficaces (gnrant du code excutable) d'une fonction doit tre limit  50 lignes, soit environ un demi cran moderne. On vitera galement l'abondance de niveaux d'imbrications._ , plus il est simple d'introduire des points de variations  la vole. Seulement si toutes sont virtuelles, cela veut aussi dire que toutes ces fonctions membre (en nombre plus ou moins important) peuvent tre supplantes. Les classes filles auraient alors une visibilit complte de la classe mre. De cette rupture d'encapsulation inter-gnrations, il devient alors vite complexe de savoir ce qui peut tre supplant, et sous quelles conditions (contraintes).
> 
> De plus, les hirarchies polymorphes ayant naturellement une smantique d'entit, dfinir virtuelle une quelconque fonction membre d'une classe  smantique de valeur n'a aucun sens. C'est aussi pour cela qu'aucun conteneur de la bibliothque  standard ne dispose de fonction membre virtuelle (voir la rgle Section 3.7.7,  _viter de driver de classes non prvues pour tre des classes de base._ ).
> ...


Un petit exemple qui illustre cela : les listes et les listes tries. Quelqu'un d'un peu naf pourra croire qu'il suffit de driver une classe liste pour dfinir une classe listetrie aprs avoir redfini la fonction d'insertion pour insrer au bon endroit. Sauf que cela sabotera compltement le contrat de la liste.


Accessoirement, la liaison tardive n'est qu'un des aspects du polymorphisme (d'inclusion -- mine de rien, le C++ en supporte 3 autres). virtual n'est pas ncessaire pour _utiliser en place de_.

----------


## Christuff

Pour moi un des plus gros dfaut du c++ ( qui vient probablement plus des compilateurs que du c++ lui mme ) est le manque d'avertissement.

Combien de fois je me suis arrach les cheveux avant de voir que j'avais initialis la variable ... ( et vu que c++ prend ce qui est a l'emplacement pointe a la place de l'initialiser .... )

un petit Warning disant "variable non initialise" ne ferait pas de mal certaines fois.

De plus je ne peux qu'tre d'accord sur l'obscurantisme des messages d'erreur des templates .. ( dommage  que a ait finalement t rejet pour le c++1x)


Cela dit je suis contre les arguments pur OO avances par certains dans ce thread, c'est,  mon avis ce qui fait la grand force du c++.
L'OO, de par le manque de formation est-ce que je considre comme un des pires flau de l'optimisation.

Certes, c'est trs pratique, et il n'y a aucune raison de s'en priver, mais il n'y a non plus aucune raison de l'vangliser.
Combien de fois un design oriente plus "data" que strictement "Object" peut nous faire gagner en performances, et c'est justement l la force du c++, nous laisser faire nos propres choix.

On retombe tout a fait dans ce qui a t dis dans certains post, le manque de formation et de gens comptents et un des plus gros problme du c++.

----------


## pseudocode

> Les fonctions  membres d'une classe ne seront pas dclares virtuelles par dfaut. Elles le seront uniquement si cette fonction correspond  un point de variation prvu lors de la conception de classe.


a me fait penser que le mot-cl "virtual" n'tait peut-tre pas le plus clair pour annoter une mthode pouvant tre redfinie. A moins de s'intresser au fonctionnement interne du runtime du C++, c'est mme assez abstrait.  ::D:

----------


## Jbx 2.0b

> La meilleure faon de savoir comment utiliser un code est de lire la documentation associ.
> Quand tu utilises une fonctionnalit de Qt par exemple, tu ne vas pas t'amuser  chercher le .h correspondant  la classe. Un rapide coup d'il sur la doc et tu as tout ce dont tu as besoin. En Java pareil avec la Javadoc.
> Et donc je ritre que la sparation du .h et du .c est une complexit en plus pour rien (ou si vous voulez pour une chose que l'on peut faire autrement et proprement).


Et j'ajouterais qu'avec des diteurs modernes comme Eclipse, quand on programme en Java(c'est aussi valable pour C# sous VStudio), on peut rduire le code aux dclarations de mthodes/classes (grce au symbole +). Une fois rduit le fichier ressemble  un .h. Sauf qu'en Java ou C# pas de redondance .h/.cpp...

Je suis largement pro-C++ mais il faut avouer qu'en terme de productivit le couple Java/Eclipse explose littralement C++/Visual ou tout autre diteur que j'ai pu tester. En C++ je me retrouve  recopier sans cesse du code, alors qu'en Java je peux remplir des pages en tapant quelques lettres et en jouant du click (ah la compltion sur une lettre quel bonheur <3 ).
Mon seul espoir rside dans QtCreator qui reprend justement beaucoup de principes d'Eclipse ( dtections d'erreurs de syntaxes  la vole, compltion bien plus avance que VC++...).

----------


## SKone

> Tout a et 99.99% du reste est crit en C/C++ , gnralement aux tats unis !


Je n'est pas d'info l dessus par contre :
d'aprs un confrencier au TechDays 80% des richesses produites par le dveloppement logiciel est fait par 5% des entreprises qui font du C++. Ce qui est normal lorsque l'on sait qu'il y a Windows, Visual Studio, Office et de nombreux autre et surtout quasiment toute l'industrie vido ludique ce qui fait beaucoup d'argent...

----------


## jblecanard

Salut




> La meilleure faon de savoir comment utiliser un code est de lire la documentation associ.
> Quand tu utilises une fonctionnalit de Qt par exemple, tu ne vas pas t'amuser  chercher le .h correspondant  la classe. Un rapide coup d'il sur la doc et tu as tout ce dont tu as besoin. En Java pareil avec la Javadoc.
> Et donc je ritre que la sparation du .h et du .c est une complexit en plus pour rien (ou si vous voulez pour une chose que l'on peut faire autrement et proprement).


Ca mon cher, c'est vrai dans un beau monde utopique ou tout le code livr est document. Quand tu dveloppes en environnement industriel, les codes des collgues sont mieux documents par les *.h que par autre chose.

Je suis par contre d'accord pour dire que la dualit *.h/*.cpp est un peu lourde, mais elle prsente tout de mme des avantages. C'est plus facile pour moi de lire les *.h des collgues que de lire des implmentations directement. Elle a aussi le mrite de sparer la description structurelle des objets et le code procdural applicatif dans deux fichiers diffrents. Ce n'est pas si mal.

----------


## saad.hessane

> Ca mon cher, c'est vrai dans un beau monde utopique ou tout le code livr est document.


a par contre c'est la faute au chef d'quipe qui n'a pas entretenu la qualit de son code. Je peux comprendre que du temps de la cration du C++, la plupart des informaticiens taient des barbues dans leurs caves qui avaient la flemme d'crire de la doc. Il fallait bien faire une sparation claire entre l'implmentation et la dclaration pour favoriser la r-utilisabilit. Aujourd'hui avec une dizaine(centaine?) de petites quipes de 5 personnes, le minimum est une doc bien faite. C'est plus important que le code lui mme. D'ailleurs tous les outils actuels permettent l'ajout simplifi de commentaire pour chaque action effectue par un membre de l'quipe.

----------


## JeitEmgie

Est-ce que srieusement on peut se passer du .h (ou quivalent) pour des langages compils en code natif ?

Si Java et assimils peuvent s'en passer c'est que le mcanisme de Reflection et le parsing du byte code permet de connatre exactement le prototype d'une mthode

Une fois compil - et sans l'aide de fichier de symboles pour le debugging - il ne reste plus que la taille des paramtres sur le stack dans le binaire 
mme l'ordre des paramtres peut-tre affect par des pragma
(par exemple pour indiquer l'ordre "Pascal" plutt que "C")
ou le namespace ("C" ou "C++") qui va affect l'dition des liens

le "header file" reste, faute de mieux, la solution la plus pratique pour donner le minimum d'informations ncessaires pour utiliser une librairie compile dont on ne dispose pas des sources


et pour ce qui est de la POO et C++ :

"Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.",
Alan Kay

----------


## saad.hessane

> Est-ce que srieusement on peut se passer du .h (ou quivalent) pour des langages compils en code natif ?
> 
> Si Java et assimils peuvent s'en passer c'est que le mcanisme de Reflection et le parsing du byte code permet de connatre exactement le prototype d'une mthode
> 
> Une fois compil - et sans l'aide de fichier de symboles pour le debugging - il ne reste plus que la taille des paramtres sur le stack dans le binaire 
> mme l'ordre des paramtres peut-tre affect par des pragma
> (par exemple pour indiquer l'ordre "Pascal" plutt que "C")
> ou le namespace ("C" ou "C++") qui va affect l'dition des liens
> 
> le "header file" reste, faute de mieux, la solution la plus pratique pour donner le minimum d'informations ncessaires pour utiliser une librairie compile dont on ne dispose pas des sources


a par contre je n'y avais pas pens  ::oops::

----------


## bacelar

J'interviens juste pour faire quelques remarques :

Ne prenez pas le C/C++ pour les Dieux des langages.
Beaucoup de firmeware utilisent des langages adhoc, beaucoup de BIOS (celui des Mac notamment) utilisent du Forth, qui est bien plus adapt pour faire du code compact et performent que le C.
Le problme du Forth, c'est qu'il est spcialis et donc avec trs peu de fonctions.
A la fin, code natif ou code interprt, cest du code machine, qui est un langage, qui est excut. Sans compter le microcode dans les CPU.

C/C++ sont des langages *polyvalents* qui ont servi au dbut dans les OS, doit leur omniprsence dans ce domaine (plus le C que le C++). Mais les OS ont gnralement besoin d'tre polyvalents, mais rarement les applications. Le dveloppeur, lui, aime tre polyvalent donc un ddain/peur des langages spcialiss.

Il ne faut pas non plus se leurrer, un avantage indniable pour l'acceptance du C++ tait sa proximit suppos avec le C.
Maintenant, cela joue en sa dfaveur mais on ne peut pas tous avoir.

Le fait de la multitude d'intervenant dans la norme C++ peut expliquer bien des choses que je voudrais souligner par un exemple.

Bon nombre de personnes n'aime pas le diptyque .H/.CPP. D'autres trouve cela indispensables pour une bonne organisation.
Les deux ont raison et le fait qu'il y ai un nombre trs important d'intervenant dans C++, interdit de compenser des lourdeurs par de l'outillage.

Si l'on prend des langages comme C# ou Java, avec les IDE VS et Eclipse, les outils de refactoring influences directement le langage.

La qualit d'un langage tient, maintenant que la puissance CPU des stations des dveloppeurs est "considrables", normment dans son "cosystme".

Le C++, par son ouverture, ne dispose pas actuellement d'un cosystme aussi efficace au niveau productivit. Quantitativement, grce  Intellisence par exemple, mais aussi qualitativement, par les outils de tests automatiques et d'analyse de code.
"lint" contre "Code Analysis" : au moins 20 ans d'cart.

Je pense que le fait que le C++ reste un langage "Notepade-aware" bride normment son volution.
Les fichiers den-tte ont t conus pour acclrer la compilation. Noubliez pas que C a t conu au dbut des annes 70, sur des PDP-11 je crois.
Avec un IDE, quil y est un fichier den-tte ou pas ne devrait tre quun dtail qui ninfluence pas le langage.
Java qui dbut publiquement en 1995 sur Pentium Pro na pas les mme contraintes.
Le fait de dfinir des interfaces avec les .h nest quun effet de bord, vertueux je ladmets, mais  ne remplace par la dfinition de vrais interfaces. Un IDE peut facilement faire lextraire lAPI dune classe de manire automatique (facile aujourdhui mais pas en 1971)

En rsum, le langage nest pas le problme, cest sont cosystme htrogne qui bride son volution aux besoins des annes 2010 et non aux besoins de 1971 (C) ou de 1985 (C++).

----------


## jblecanard

Salut




> a par contre c'est la faute au chef d'quipe qui n'a pas entretenu la qualit de son code.


Mme ide, le jour ou tous les chefs d'quipe pourront toujours tout faire proprement et document dans le dlai impos par leur suprieur n'est pas arriv, sinon a se saurait. Il y a effectivement des commentaires formats, et nous nous en servons, et c'est ce qui sert de doc. Commentaires + signatures des mthodes, dans la majorit des cas, c'est une doc suffisante pour dvelopper. Dans mon cas, on est 2000  taffer en intgration continue sur un code commun, alors autant te dire qu'au niveau qualit, il y a un suivi et des outils assez pousss, sinon a se casse vite la gueule  :;): .

Mais qu'on soit bien clair : l je parle de code en interne. le code expos aux clients est document, cela va de soi.

----------


## Luc Hermitte

> a- un petit Warning disant "variable non initialise" ne ferait pas de mal certaines fois.
> 
> b- De plus je ne peux qu'tre d'accord sur l'obscurantisme des messages d'erreur des templates .. ( dommage  que a ait finalement t rejet pour le c++1x)


a- Ne dclare plus jamais une variable autrement que const (ou comme indice de boucle-for), et tu verras ce problme disparaitre.
La rgle en C++ est de toujours retarder la dfinition d'une variable jusqu'au moment o l'on peut l'initialiser  une valeur qui a du sens, et de prfrence  une valeur finale.
Maintenant, une fois de plus l'hritage de langages d'une autre poque font que beaucoup croient qu'il est plus propre de dclarer toutes les variables en dbut de fonction -- et  ct de a ils feront des fonctions de 3km de long sans sourciller.

b- les concepts reviendront peut-tre pour une prochaine mouture, en attendant il y a toujours STLfilt (je vous ai parl de STLfilt ? (je ne sais pas pourquoi, je sens que cela va revenir))

----------


## jblecanard

> Pour moi un des plus gros dfaut du c++ ( qui vient probablement plus des compilateurs que du c++ lui mme ) est le manque d'avertissement.
> 
> Combien de fois je me suis arrach les cheveux avant de voir que j'avais initialis la variable ... ( et vu que c++ prend ce qui est a l'emplacement pointe a la place de l'initialiser .... )
> 
> un petit Warning disant "variable non initialise" ne ferait pas de mal certaines fois.


Il existe des outils pour la qualit logicielle qui permettent de dtecter ce genre de choses. Je ne dis pas que c'est le top et que c'est facile  utiliser, mais si ce genre de problmes te cote du temps, ce peut tre une solution.

----------


## koala01

Salut,

Je crois qu'il faut commencer par rendre  Cesar ce qui appartient  Cesar, ou plutt, par ne rendre C++ responsable que de... ce dont il est responsable.

J'ai en effet lu sur la premire page de nombreuses interventions qui semblaient rendre C++ responsables de ce que les gens en font, parmi lesquelles ( peu prs dans l'ordre dans lequel elles sont apparues) :

Les gens qui enseignent/pratiquent le C++ comme du CLes diffrentes implmentations des compilateurs ...J'en pointerais un beaucoup plus simple: l'illisibilit...Pas d'diteur aussi puissant qu'on peut en trouver dans le monde Java par exempleles carts et omissions des diffrents compilos par rapport au standard
Comprenons ce sont les utilisateurs et / ou les gens qui implmentent le compilateur les vrais responsables de ces travers:

 1 -Si les gens pratiquent et enseignent C++ comme du C, c'est peut tre en partie du  sa filiation historique avec C, mais c'est surtout du au fait que de trop nombreux enseignants / dveloppeurs n'ont pas encore jug utile de... se remettre en question...

2 et 5 - Le respect et le support trs ingale de la norme n'est du... qu'aux dveloppeurs de compilateur, dont certains taient connus  une poque pour leur habitude de faire fi des normes.

Notez cependant que les choses voluent dans le bon sens, car la plupart des fournisseurs de compilateur dont je parle ont chang leur fusil d'paule, et tendent  faire en sorte de suivre la norme par dfaut.

Notez que l'utilisateur a aussi sa part de responsabilits, dans le sens o C et C++ sont sans doute les seuls langages pour lesquels il continue  utiliser des compilateurs vieux de plus de dix ans...

3 - L'illisibilit du code :  Il est vrai que C++ permet de rendre un code illisible, mais, encore une fois, c'est un choix du programmeur que de le faire.

On ne peut reprocher un code illisible... qu'au programmeur qui l'a crit.

De plus, il est tout  fait possible d'crire du code illisible dans n'importe quel langage  :;): 

4 - L'absence d'diteurs "aussi puissant que ce que l'on trouve en java" est beaucoup plus du au fait qu'on ne trouve personne pour les crer qu' au langage lui-mme

Vous me direz sans doute que, si C++ ne laissait pas la porte ouverte  tous ces problmes, ils (ces problmes) n'existeraient pas.

Mais bon, le code de la route interdit aussi de rouler  plus de 120 ou 130 (selon le pays) sur l'autoroute, ce n'est pas pour cela que personne ne le fait  ::D:

----------


## ManusDei

> Maintenant, une fois de plus l'hritage de langages d'une autre poque font que beaucoup croient qu'il est plus propre de dclarer toutes les variables en dbut de fonction -- et  ct de a ils feront des fonctions de 3km de long sans sourciller.


a rend la relecture vachement simple, quand on veut savoir  quoi sert une variable en milieu de programme, on remonte au dbut de la fonction et elle est l (commente bien entendu  ::aie:: ). Rien  voir avec des questions de rapidit ou propret.

----------


## pseudocode

> Vous me direz sans doute que, si C++ ne laissait pas la porte ouverte  tous ces problmes, ils (ces problmes) n'existeraient pas.


Tout a fait. Nous sommes dans les annes 2010 et un environnement de dveloppement se doit d'tre un minimum "idiot proof". Ca inclut l'IDE, le compilo et les specs du langage.

Comme a a t dit, c'est termin le temps o seuls les barbus nvropathes avaient la science ncessaire pour coder une boucle for().

Aujourd'hui les dveloppeurs se doivent d'apprendre un langage en un temps trs court avec pour seul guide les tutoriels, docs, exemples, ... Pas le temps d'apprendre les concepts, fondements et autres paradigmes qui sous-tendent le fonctionnement.

La programmation tait un art, c'est aujourd'hui un job.

Donc si le C++ permet trop facilement de se tirer une balle dans le pied et d'y laisser sa jambe, et bien il y a fort  parier que les quipes seront pleines d'unijambistes.  ::P:

----------


## bioinfornatics

j'ai souffert des mme problmes en C++, puis dans un lan de motivation je suis pass au D. Ce langage corrige de nombreuse critique dcrite par mes collgues prcdemment.
Maintenant en D ce que je peux lui reprocher ces a jeunesse, en effet de nombreuses lment sont propos nativement ou dans la bibliothque standard mais elle ne couvre forcment pas des cas prcis.  Ce qui ne m'empche pas de l'avoir adopt.

----------


## koala01

> Tout a fait. Nous sommes dans les annes 2010 et un environnement de dveloppement se doit d'tre un minimum "idiot proof". Ca inclut l'IDE, le compilo et les specs du langage.
> 
> Comme a a t dit, c'est termin le temps o seuls les barbus nvropathes avaient la science ncessaire pour coder une boucle for().
> 
> Aujourd'hui les dveloppeurs se doivent d'apprendre un langage en un temps trs court avec pour seul guide les tutoriels, docs, exemples, ... Pas le temps d'apprendre les concepts, fondements et autres paradigmes qui sous-tendent le fonctionnement.
> 
> La programmation tait un art, c'est aujourd'hui un job.
> 
> Donc si le C++ permet trop facilement de se tirer une balle dans le pied et d'y laisser sa jambe, et bien il y a fort  parier que les quipes seront pleines d'unijambistes.


Il se fait que, justement, les documents qui proposent  l'apprentissage du code parfaitement lisible sont malgr tout la grande majorit.

Mais combien de programmeurs perdent des heures entires  supprimer tout retour  la ligne et toute indentation uniquement "pour faire ch... le voisin" et parce que le langage leur permet  ::question:: 

Le langage se doit, effectivement, d'tre plus ou moins idot-proof, mais est-ce  lui d'empcher ses utilisateurs d'tre c ::aie::   ::question::

----------


## pseudocode

> Il se fait que, justement, les documents qui proposent  l'apprentissage du code parfaitement lisible sont malgr tout la grande majorit.
> 
> Mais combien de programmeurs perdent des heures entires  supprimer tout retour  la ligne et toute indentation uniquement "pour faire ch... le voisin" et parce que le langage leur permet 
> 
> Le langage se doit, effectivement, d'tre plus ou moins idot-proof, mais est-ce  lui d'empcher ses utilisateurs d'tre c


On ne peut pas empecher une dev de faire volontairement de l'obfuscation. Par contre il faudrait l'empecher de le faire par inadvertance. 

Par exemple, en Java, j'ai toujours trouv choquant qu'une variable et une mthode puissent avoir le mme nom, sans dclencher le moindre warning du compilo.  ::(: 

A l'inverse, le C++ gnre tellement de warning qu'on n'y fait plus vraiment attention. Il y a meme des flags de compilation pour grer le niveau de warning.  ::aie::

----------


## koala01

> On ne peut pas empecher une dev de faire volontairement de l'obfuscation. Par contre il faudrait l'empecher de le faire par inadvertance. 
> 
> Par exemple, en Java, j'ai toujours trouv choquant qu'une variable et une mthode puissent avoir le mme nom, sans dclencher le moindre warning du compilo.


Ce serait donc un argument en faveur de C++, ca, non  ::question:: 



> A l'inverse, le C++ gnre tellement de warning qu'on n'y fait plus vraiment attention. Il y a meme des flags de compilation pour grer le niveau de warning.


A titre personnel (et je connais pas mal d'intervenants qui font pareil  ::D: ), je place, justement, les flags de compilation de sorte  avoir un maximum d'avertissement, et je fais en sorte d'apporter une solution  tous.

Je conois que certains aient une approche diffrente, mais, encore une fois, il ne faut pas rendre le langage responsable de l'incurie de ceux qui l'utilisent  ::D:

----------


## stardeath

> On ne peut pas empecher une dev de faire volontairement de l'obfuscation. Par contre il faudrait l'empecher de le faire par inadvertance.


volontairement c'est idiot, c++ est un langage qui, compil, ne permet pas de retrouver le code source d'origine, pas comme java par exemple.

----------


## jblecanard

> A titre personnel (et je connais pas mal d'intervenants qui font pareil ), je place, justement, les flags de compilation de sorte  avoir un maximum d'avertissement, et je fais en sorte d'apporter une solution  tous.


Je fais de mme, mais trop de gens se disent "c'est un warning alors osef". Le problme se situe clairement entre la chaise et le clavier.

----------


## koala01

> <snip> Le problme se situe clairement entre la chaise et le clavier.


Exactement...

C'est pour cela que je plaide pour qu'on ne rende le langage (quel qu'il soit) responsable que de ... ce qui est de sa responsabilit.

Il n'y a rien  faire, il y a les "bons" programmeurs et les... moins bons (voir mdiocres).

Aucun langage ne pourra transformer les moins bons d'un coup de baguette magique, aussi balis puisse-t-il tre dans sa philosophie  ::D: 

Tout au plus, il est possible que le langage permette de cacher la mdiocrit du programmeur ou du dveloppeur... Mais c'est,  mon sens, le pire service qu'il puisse leur rendre (et surtout qu'il puisse rendre  la socit qui les utilise  ::D: )

----------


## JeitEmgie

Pour ceux que les dveloppements autour du C/C++ intressent :

The LLVM Compiler Infrastructure

----------


## Florian Goo

Piti, arrtez d'crire  C/C++  : malgr l'historique qui les lie, ce sont deux langages diffrents !
En plus de vous discrditer, a entretient une confusion qui n'a pas lieu d'tre.

EDIT : Ce message n'tait pas destin  mon voisin du dessus, mais aux quelques messages prcdents.

----------


## JeitEmgie

> Piti, arrtez d'crire  C/C++  : malgr l'historique qui les lie, ce sont deux langages diffrents !
> En plus de vous discrditer, a entretient une confusion qui n'a pas lieu d'tre.


arrtez de crier au loup sans avoir t voir le site en question
c'est vous qui vous vous discrditez

le projet LLVM concerne C, C++ et mme Objective-C

(et mme  travers GCC les autres langages supports par celui-ci)

----------


## bioinfornatics

LLVM support galement le D avec LDC
D'ailleur dans fedora 14 il y aura intgration de LDC et tango pour dev en D.
j'espre aussi d'autre bibliotheque D.

----------


## pseudocode

> Ce serait donc un argument en faveur de C++, ca, non


Oui et non. Le C++ gnre surement un warning pour ce problme (en fait, j'en sais rien  ::aie::  ). Mais le C++ gnre des warning pour tout un tas de choses qui  mon sens ne devraient pas tre possible (c'est a dire interdites par les specs du langage). Par exemple transformer un pointeur sur objet en void*

----------


## jblecanard

> Oui et non. Le C++ gnre surement un warning pour ce problme (en fait, j'en sais rien  ). Mais le C++ gnre des warning pour tout un tas de choses qui  mon sens ne devraient pas tre possible (c'est a dire interdites par les specs du langage). Par exemple transformer un pointeur sur objet en void*


Il y a des tas de choses qui ne peuvent pas tre interdites  cause de la rtrocompatibilit avec C.

----------


## pseudocode

> Il y a des tas de choses qui ne peuvent pas tre interdites  cause de la rtrocompatibilit avec C.


C'est bien le problme. Il n'existe pas de C++ "strictement" Objet. Seul la volont du programmeur permet de maintenir le respect des rgles de ce paradigme de programmation.

----------


## zul

Le C++ n'est pas un langage Objet, "strictement" ou pas. Ce n'est pas son but. C'est un langage multi-paradigme, o l'on essaye de choisir le bon paradigme pour rsoudre le problme, et pas dsesprement de coller le problme dans un paradigme quelconque. 
On peut considrer a comme un dfaut (pour tous les gens endoctrins au sacro-saint objet, a demande de rflchir diffrement, code pas forcment homogne) ou comme un avantage (a permet de rsoudre le problme au "mieux", on n'est pas "brid" par le design du langage ...). (Et non le pur objet n'est pas la rponse  tous les problmes informatiques comme on voudrait bien le faire croire).

Quand je vois "void*" dans un code en C++, je commence  m'inquiter srieusement  la base.

----------


## koala01

> Oui et non. Le C++ gnre surement un warning pour ce problme (en fait, j'en sais rien  ). Mais le C++ gnre des warning pour tout un tas de choses qui  mon sens ne devraient pas tre possible (c'est a dire interdites par les specs du langage). Par exemple transformer un pointeur sur objet en void*


Je crois que tu confond ce qui est interdit avec ce dont tu estime que cela ne devrait pas tre autoris.

Il n'y a rien  faire, ce qui est interdit doit provoquer une erreur. Pour le reste...

Le souhait de garder une compatibilit aussi grande que possible avec le C est une dcision qui ne sera sans doute jamais remise en question, qui implique qu'il faille "faire avec" dans certaines situations.

Le principal problme rencontr est alors que l'on ne peut pas dcider d'interdire quelque chose qui soit autoris en C, mme s'il s'agit de quelque chose qui n'est dcidment pas conseill en C++.

De plus, Ce n'est pas parce que, dans ta vision des choses, une manire de procder ne devrait pas tre autorise (sans doute parce que tu ne t'es jamais trouv face  une situation dans laquelle tu n'avais pas le choix) que d'autres n'ont pas besoin de cette possibilits dans des situations bien particulires et en toute connaissance de cause.

Il est donc "logique" que la dcision de recourir  cette possibilit produise un avertissement ("attention, si vous persistez dans cette voie, soyez sur de ce que vous faites") et non une erreur.

Au final, le principal problme de C++ (ou du moins la base de tous ses problmes) est peut tre sa philosophie de maintenir  tout prix une compatibilit accrue avec C.

Mais, comme je l'ai dit, c'est un aspect qui ne semble pas prs  tre rediscuter  ::aie::

----------


## pseudocode

> Je crois que tu confond ce qui est interdit avec ce dont tu estime que cela ne devrait pas tre autoris.


Je ne confond pas. Je ne fais que rpondre aux questions poses dans le PO (et accessoirement dans le titre de la discussion).  ::D: 

En plus, il me semble bien avoir crit "des choses qui * mon sens* ne devraient pas tre possible".


Peace &  ::heart::

----------


## koala01

> Je ne confond pas. Je ne fais que rpondre aux questions poses dans le PO (et accessoirement dans le titre de la discussion). 
> 
> En plus, il me semble bien avoir crit "des choses qui * mon sens* ne devraient pas tre possible".


Mea Culpa...

Je voulais en fait crire "c'est l qu'il est temps de distinguer clairement ce qui est interdit de ce qui ne devrait  ton sens pas tre autoris".

Car cette distinction est primordiale dans le sens o ce n'est effectivement pas parce que quelque chose n'est, a priori, pas une bonne ide qu'elle ne puisse tre considre, dans certaines circonstances, comme "la moins mauvaise solution"  ::D:

----------


## Invit

Je ne comprends pas bien cette volont de normer un language. C tait un language parfaitement norm au dbut. C++ est venu mettre le souk mais rien n'empche de respecter votre norme 

Pourquoi diable voulez vous interdire ?  Le principe fondateur des langages de cette gnration est d'AUTORISER et non pas interdire.   
Ensuite un langage comme C est fait pour manager un processeur et non pas un programmeur !  Les langages comme C# consomment du CPU pour faciliter la tache du dev et c'est pourquoi C est plus rapide  l'excution (les dveloppeurs ARM apprcieront)

Le C n'est pas le langage qui gche C++ , c'est son anctre et  la reflexion , son frre siamois. Le C permet des choses que C++ ne permet pas et ils sont effectivement indissociables. C/C++ est un terme parfaitement recevable.

Enfin, Si vous trouvez le C++ trop brouillon , passez en manag ! dotnet fera la garbage collection  votre place et vous pourrez oublier de librer les ressources comme en C# ou Java.

Objective-C est le language C systme de MAC OS ? en tout cas celui de l'iPhoenet iPad , comme MSC est celui de windows et GCC celui de linux. Ces compilateurs sont bass sur les mmes prceptes  quelques dtails prs.

Il ressort de vos messages que vous seriez plus heureux en C# ou en Java qu'en C++ (c'est mon cas sous windows). Pourquoi s'acharner sur un langage qui n'a pas besoin de vous pour exister ?  le plus complexe de tous  ? Les fameux 5% d'diteurs amricains qui font 80% du CA IT ne parlent pas franais et vous diront la mme chose ! Ils ont des quipes suprieures  5 000 dveloppeurs , et vous ?   Si vous ne faites pas de QT ni d'iPhone, que Linux vous laisse froids et que vous voulez faire des applis aussi belles qu'en C++ , 3 fois plus vite, 10 fois moins galre  debugger, qui renvoient les messages que vous attendez quand vous les attendez, utilisez le langage qui vous a inspir ces rflexions (Java, C#) et oubliez C++ qui va blanchir votre teint, vous faire abuser du caf et vous rendre irritables ...

Encore une fois , C++ et C sont des standards absolus, mais il y a beaucoup de business dans les autres langages.  C++ est rserv aux experts , plutt clibataires, capables de manger de la pizza froide  3h du mat et qui s'acharnent 70h par semaine minimum sur leur job.   

Quant  la POO, je suggre un entrainement sur les gnrateurs de visual Studio C# qui donnent une bonne ide du minimum vital en matire d'objet.

Ensuite en rflchissant ,  Vous verrez le parti que vous pouvez en tirer. 
En ce qui me concerne , je me passe trs bien des objets qui sont absents en embarqu (C), je fais exactement la mme chose avec que sans ! Mais ce que je ne sais pas faire en procdural , c'est supprimer un mgabyte de variables globales !  En fait c'est impossible, et si l'objet sert  une chose , c'est bien  a ! Le reste , vos tudes, votre pays vous l'ont inculqu mais certainement pas les langages qui ne vous forcent pas  faire de l'object maniac , vous vous l'imposez.

Si vous voulez absolument mettre des tonnes d'objets, votre programme aura des problmes.  L'objet permet surtout d'optimiser la mmoire, pour le reste , c'est un peu une histoire de confort mais C++ et le confort, selon moi , a fait 2

----------


## Jbx 2.0b

Rien n'empche de faire un code insipide et pas du tout objet en Java galement, ou dans tout langage orient-objet (un autre bon exemple tant Python, que j'ai vu utilis bien souvent en faisant fit de tout ses concepts objets). 

C'est juste que n'ayant pas le pass du C++ et tant bti sur une bibliothque standard fortement orient objet et trs bien documente, pdagogiquement Java est bien meilleur sur ce point. Vous remarquerez d'ailleurs que vos professeurs de Java sont bien plus enclins  vous faire dcouvrir de nouveau Design Patterns par exemple, alors que les profs de C++ se bornent en gnral  vous faire faire de l'algorithmie.

Ce qui  mon got n'est pas toujours un mal en soit quand on  la chance d'avoir eu des cours dans les deux langages.

----------


## pseudocode

> Mea Culpa...
> 
> Je voulais en fait crire "c'est l qu'il est temps de distinguer clairement ce qui est interdit de ce qui ne devrait  ton sens pas tre autoris".
> 
> Car cette distinction est primordiale dans le sens o ce n'est effectivement pas parce que quelque chose n'est, a priori, pas une bonne ide qu'elle ne puisse tre considre, dans certaines circonstances, comme "la moins mauvaise solution"


C'est effectivement une affaire de choix personnel. Pour ma part, je ne vois aucune raison de faire en C++ ce que je peux faire en C, et inversement ( et gnralement, le compilateur C n'est jamais bien loin du compilateur C++). Ma frontire "conceptuelle" entre ces deux langages est assez nette pour savoir de quel cot je me trouve. Le franchissement est quelque chose que je m'interdis dans la mesure du possible (et que j'interdis aux autres, dans la mesure o j'ai mon mot a dire). 

Appelez a bonne pratique, ou rgle de programmation. Je trouve juste dommage que le langage lui-mme ne soit pas plus strict sur ce point. Pour un langage "industriel", je le trouve un peu trop permissif.

----------


## koala01

> Je ne comprends pas bien cette volont de normer un language. C tait un language parfaitement norm au dbut. C++ est venu mettre le souk mais rien n'empche de respecter votre norme


Simplement parce que, comme C, il est arriv un temps o plusieurs socits produisaient leur propre compilateur en "tirant dans tous les sens" et souvent de manire non portable.

Nous en arrivions donc  des situations dans lesquelles un code jug tout  fait correct et valide par un compilateur tait totalement incomprhensible par un autre.

Le fait d'crire une norme pour un langage de programmation permet de s'assurer que, si un code qui respecte cette norme est crit, il sera compil de manire similaire par tout compilateur qui la respecte galement.

Tu sais, les normes font partie de la vie courante, et pas seulement en informatique  ::D: 

C'est parce qu'il y a des normes que tu peux brancher sans peine n'importe quel appareil lectrique dans n'importe quelle prise adquates  :;): 



> Le C n'est pas le langage qui gche C++ , c'est son anctre et  la reflexion , son frre siamois. Le C permet des choses que C++ ne permet pas et ils sont effectivement indissociables. C/C++ est un terme parfaitement recevable.


C'tait vrai au dpart, lorsque C++ s'apparentait beaucoup plus  du "C with classes"

Actuellement, s'il reste toujours possibles d'utiliser les possibilits issues de C en C++ car C++ ne renie pas ses origines et a inscrit dans sa "constitution" ce souhait de compatibilit, l'approche "moderne" consiste  utiliser en priorit les possibilits propres  C++ et  dconseiller l'utilisation de celles issues de C.

Une grosse part de la justification de cette approche vient de la scurisation accrue des possibilits propres  C++ et  une utilisation finalement plus facile et plus sereine.



> Encore une fois , C++ et C sont des standards absolus, mais il y a beaucoup de business dans les autres langages.  C++ est rserv aux experts , plutt clibataires, capables de manger de la pizza froide  3h du mat et qui s'acharnent 70h par semaine minimum sur leur job.


Ainsi faite, ta remarque a quelque chose de trs dsobligeant...

Je ne suis surement pas le seul "C++iste"  ne pas me reconnaitre du tout dans cette description  ::aie:: 

Si au moins tu avais dit que c'taient des langages plutt destins  ceux qui veulent garder le contrle complet sur ce qu'il font et sur les dcisions qu'ils prennent, j'aurais sans doute ragit diffremment  ::D: 



> Quant  la POO, je suggre un entrainement sur les gnrateurs de visual Studio C# qui donnent une bonne ide du minimum vital en matire d'objet.


Chaque langage dfini une politique qui lui est propre et en tire les conclusion qu'elle impose.

Il ne me semble pas opportun de relance un dbat (qui existe par ailleurs) C++ Vs C#/java ici, mais le minimum vital que les gnrateurs pourront proposs risquent,  mon sens, d'tre trs fortement brids par la philosophie propre au langage  ::aie:: 

De plus, j'ai dj eu l'occasion  maintes reprises de constater que ceux dont l'apprentissage objet tait bas sur des langages comme java ou C# n'avaient souvent qu'une approche... trop inspire par les philosophies respectives de ces langages, et passaient  cot de d'un certain nombre de principes, simplement parce qu'ils taient difficilement applicables en tant que tels (sans avoir subi une adaptation rendue ncessaire par la philosophie du langage).



> Si vous voulez absolument mettre des tonnes d'objets, votre programme aura des problmes.


Pas forcment...

Un projet exclusivement orient objet ne posera pas forcment plus de problme qu'un projet exclusivement procdural, ni l'inverse d'ailleurs.

Seule l'incomprhension et / ou la mauvaise mise en oeuvre de certains principes risque de poser problme... Mais c'est valable pour n'importe quel paradigme  ::P: 



> L'objet permet surtout d'optimiser la mmoire, pour le reste , c'est un peu une histoire de confort


C'est trs rducteur comme approche...

Mais je ne t'en voudrai pas de prfrer rester  la programmation procdurale, si tu te sens plus  l'aise avec ce paradigme  ::D: 



> mais C++ et le confort, selon moi , a fait 2


Absolument pas...

Simplement, il te permet de choisir le confort dont tu as besoin et pour lequel tu es d'accord de payer le prix.

Si vim ou emacs te suffisent, libre  toi de les utiliser... mais n'empche pas les autres de choisir d'autres diteurs  ::D:  (bon, d'accord, ca, ca n'a rien  voir avec le langage  ::D: )

----------


## koala01

> C'est effectivement une affaire de choix personnel. Pour ma part, je ne vois aucune raison de faire en C++ ce que je peux faire en C, et inversement ( et gnralement, le compilateur C n'est jamais bien loin du compilateur C++). Ma frontire "conceptuelle" entre ces deux langages est assez nette pour savoir de quel cot je me trouve. Le franchissement est quelque chose que je m'interdis dans la mesure du possible (et que j'interdis aux autres, dans la mesure o j'ai mon mot a dire).


Soyons clair...

Je tend galement  limiter au maximum les points de jonction entre du code C et du code C++, et je me retrouve pleinement dans cette optique d'interdire "autant que faire se peut" les franchissements de frontire.

Cela ne m'empche par contre pas de constater que ces franchissements sont rgulirement ncessaires, ne serait-ce que par l'utilisation de bibliothques crites  l'origine en C, et donc par la ncessit de s'accorder certaines latitudes.



> Appelez a bonne pratique, ou rgle de programmation. Je trouve juste dommage que le langage lui-mme ne soit pas plus strict sur ce point. Pour un langage "industriel", je le trouve un peu trop permissif.


Comme je l'ai dj dit, c'est malheureusement le prix  payer pour garantir la compatibilit maximale.

Ce n'est pas prs de changer, il faut donc "faire avec" et, surtout, cette permissivit est parfois indispensable pour certains projets  :;):

----------


## Florian Goo

> arrtez de crier au loup sans avoir t voir le site en question
> c'est vous qui vous vous discrditez
> 
> le projet LLVM concerne C, C++ et mme Objective-C
> 
> (et mme  travers GCC les autres langages supports par celui-ci)


Il y a confusion. J'ai crit mon message avant de lire le tiens et il se trouve qu'il a t plac juste aprs le tiens, mais il ne t'tait pas destin  :;): .

----------


## Florian Goo

> Oui et non. Le C++ gnre surement un warning pour ce problme (en fait, j'en sais rien  ). Mais le C++ gnre des warning pour tout un tas de choses qui  mon sens ne devraient pas tre possible (c'est a dire interdites par les specs du langage). Par exemple transformer un pointeur sur objet en void*


Concernant ce type de casts, ce n'est pas pour rien que les casts  la C++ (static_cast, dynamic_cast, etc.) ont t crs ! Dans le genre  bonne pratique , on est bien loin de la prise de tte.





> Je ne comprends pas bien cette volont de normer un language.


Cette remarque me rend perplexe. Normaliser un langage permet de rendre compatibles plusieurs implmentations de compilateurs, d'analyseurs de code, d'outils d'assistance  l'ingnierie informatique en gnral.
On peut mme comparer cela  l'un des grands principes de la POO : le principe d'inversion des dpendances. On se rend dpendant d'une interface (la norme) et non d'une classe d'implmentation (un compilateur en particulier).




> C tait un language parfaitement norm au dbut.


Totalement faux : avant sa normalisation, on comptait quasiment autant d'implmentations du langage que de plateformes.




> C++ est venu mettre le souk mais rien n'empche de respecter votre norme


De quelle faon ?




> Pourquoi diable voulez vous interdire ?  Le principe fondateur des langages de cette gnration est d'AUTORISER et non pas interdire.


Je partage avec Koala l'ide qu'aujourd'hui, le C++ traine la rtro-compatibilit vers le C plus comme un boulet qu'autre chose.
Pour reprendre mon exemple du dbut du message, si l'on _interdisait_ l'utilisation des casts  la C (de la forme  (type)variable ) pour imposer l'utilisation des casts  la C++ (static_cast, dynamic_cast, etc., bien plus expressifs sur le type de conversion et transtypage que l'on souhaite autoriser), le langage s'en trouverait amlior (si l'on oublie les avantages que prsentent la rtrocompatibilit vers le C, bien sr).
Ce type d'_interdictions_ ne bride en rien le contrle du programmeur sur son code.




> Ensuite un langage comme C est fait pour manager un processeur et non pas un programmeur !  Les langages comme C# consomment du CPU pour faciliter la tache du dev et c'est pourquoi C est plus rapide  l'excution (les dveloppeurs ARM apprcieront)


D'accord, mais on parle du langage C++, ici, pas du langage C. Une comparaison C vs C# n'a absolument pas lieu d'tre.




> Le C n'est pas le langage qui gche C++ , c'est son anctre et  la reflexion , son frre siamois. Le C permet des choses que C++ ne permet pas et ils sont effectivement indissociables. C/C++ est un terme parfaitement recevable.


Pas d'accord, mais je crois qu'on en a dj dbattu dans un autre topic.
EDIT : Celui-ci, mais c'tait avec une autre personne.




> Enfin, Si vous trouvez le C++ trop brouillon , passez en manag ! dotnet fera la garbage collection  votre place et vous pourrez oublier de librer les ressources comme en C# ou Java.


S'il est un langage o la gestion des ressources est  la fois propre, efficace et sans prise de tte, c'est bien le C++. Merci la RAII et les pointeurs intelligents
Prtendre l'inverse est une mconnaissance flagrante du langage.




> Il ressort de vos messages que vous seriez plus heureux en C# ou en Java qu'en C++ (c'est mon cas sous windows).


Oh que non.




> Pourquoi s'acharner sur un langage qui n'a pas besoin de vous pour exister ?  le plus complexe de tous  ?


Complet oui, complexe non. Du moins lorsque l'on sait s'en servir.
Distinguer les pratiques respectives du C et du C++ est un bon dbut pour ne pas tomber dans la confusion.




> Les fameux 5% d'diteurs amricains qui font 80% du CA IT ne parlent pas franais et vous diront la mme chose !


Heureusement que tu es l pour parler en leur nom.




> Ils ont des quipes suprieures  5 000 dveloppeurs , et vous ?


Quel rapport ?




> Si vous ne faites pas de QT ni d'iPhone, que Linux vous laisse froids et que vous voulez faire des applis aussi belles qu'en C++ , 3 fois plus vite, 10 fois moins galre  debugger, qui renvoient les messages que vous attendez quand vous les attendez, utilisez le langage qui vous a inspir ces rflexions (Java, C#) et oubliez C++ qui va blanchir votre teint, vous faire abuser du caf et vous rendre irritables ...


Curieuse remarque l encore
Utiliser Qt n'est pas une fin en soi, mais un moyen comme un autre.
Quel rapport avec l'iPhone ? Si tu penses aux applications iPhone, il s'agit d'Objective-C et non de C++.
Quel rapport entre le C++ et Linux ??
Si tu es productif avec Java et C#, grand bien t'en fasse. Pour ma part je le suis en C++ et je deviens irritable surtout lorsqu'on me force  utiliser les langages que tu cites.




> Encore une fois , C++ et C sont des standards absolus, mais il y a beaucoup de business dans les autres langages. *C++ est rserv aux experts , plutt clibataires, capables de manger de la pizza froide  3h du mat et qui s'acharnent 70h par semaine minimum sur leur job.*


Que rpondre  une telle ineptie ? Cette affirmation est d'un pathtique




> Ensuite en rflchissant ,  Vous verrez le parti que vous pouvez en tirer. 
> En ce qui me concerne , je me passe trs bien des objets qui sont absents en embarqu (C), je fais exactement la mme chose avec que sans ! Mais ce que je ne sais pas faire en procdural , c'est supprimer un mgabyte de variables globales !  En fait c'est impossible, et si l'objet sert  une chose , c'est bien  a !


Qui a dit le contraire ?




> Le reste , vos tudes, votre pays vous l'ont inculqu mais certainement pas les langages qui ne vous forcent pas  faire de l'object maniac , vous vous l'imposez.
> 
> Si vous voulez absolument mettre des tonnes d'objets, votre programme aura des problmes.


J'adhre effectivement  l'ide que coder en objets n'est pas une fin en soi. Le tout-objet de Java me semble hautement impertinent. Mais l encore je ne sais pas trop  qui tu t'adresses




> L'objet permet surtout d'optimiser la mmoire, pour le reste , c'est un peu une histoire de confort mais C++ et le confort, selon moi , a fait 2


Les gots et les couleurs

----------


## bioinfornatics

Comme je l'ai prcdemment dit le langage D permet de rconcilier tout ce beau monde
Les messages d'erreur sont trs pertinent et explicite ce qui n'est pas le cas en C++
On garde la performance du C++ tout en gagnant en productivit.
Chre collgue j'tais spcimiste y a peu par rapport a ce langage, aprs avoir install:
- LDC compilateur D (frontend LLVM)
- tango runtime (bibliothque standard)
j'ai tait surpris de la facilit, bien sur comme tout nouveaux langage que l'on apprend faut lire la doc et les exemples, que l'on trouve ici:
- http://www.dsource.org/projects/tango/wiki/
- http://www.dsource.org/projects/tango/docs/stable/
- irc freenode: #ldc  #d #d.tango
Sincrement essayer le, les personnes venant du C++ s'adapte trs bien a ce langage car relativement proche.
Il en est de mme pour ceux venant de C# et Java

Pour moi l'avantage du D au C++ c'est qu'il ne garde pas la rtrocompatibilit du C en revanche on peut inclure du C de l'asm et bientot du C++
avec le mot cl extern ( a vous dites quelques choses  ::P:  )

----------


## Luc Hermitte

> a rend la relecture vachement simple, quand on veut savoir  quoi sert une variable en milieu de programme, on remonte au dbut de la fonction et elle est l (commente bien entendu ). Rien  voir avec des questions de rapidit ou propret.


Ce n'est pas une question d'optim.
C'est une question d'invariants : il n'y a avec cette faon de procder, nulle part dans le code un seul endroit o la variable aura un tat qui ne rime  rien (i.e. non initialis). Si c'est a que tu appelles propret, alors oui j'en veux.

Et le code est trop dur  lire ? Tu as alors deux problmes :
- fonctions trop longues (on ne le rpte jamais assez)
- mauvais outil de dveloppement (vu qu'il ne propose pas de moyens de sauter directement  l'endroit de la dclaration de la variable, ni de moyens pour mettre en couleur toutes ses occurrences)

@adeptes du D: j'attends que le langage s'toffe en bibliothques avant de pouvoir le considrer pour faire du dveloppement pro. Je ne doute pas un seul instant qu'il puisse me plaire.

----------


## koala01

> Comme je l'ai prcdemment dit le langage D permet de rconcilier tout ce beau monde


Et quel est le rapport avec la discussion actuelle  ::question:: 

S'il s'agit d'attirer les intervenants vers une discussion dans laquelle on parle des mrites compars de D et de C++, il est prfrable de crer une autre discussion (quoi que celle-ci pourrait faire l'affaire  :;): )

Si l'ide est de mettre en concurrence C++ avec les autres langages, d'autres dbats sont dj ouverts par ailleurs: N'hsite pas  visiter la section dbats du forum.

Ici, il est plutt question de permettre aux gens qui le souhaitent d'indiquer ce qui,  leurs yeux, ne va pas "comme il faut" en C++...

----------


## Invit

> Comme je l'ai prcdemment dit le langage D permet de rconcilier tout ce beau monde
> Les messages d'erreur sont trs pertinent et explicite ce qui n'est pas le cas en C++
> On garde la performance du C++ tout en gagnant en productivit.
> Chre collgue j'tais spcimiste y a peu par rapport a ce langage, aprs avoir install:
> - LDC compilateur D (frontend LLVM)
> - tango runtime (bibliothque standard)
> j'ai tait surpris de la facilit, bien sur comme tout nouveaux langage que l'on apprend faut lire la doc et les exemples, que l'on trouve ici:
> - http://www.dsource.org/projects/tango/wiki/
> - http://www.dsource.org/projects/tango/docs/stable/
> ...


Cool !!  je sais que le topic est que reprocher  C++ mais franchement les objects maniac ont besoin d'autre chose . D me semble trs pertinents

Au fait , j'ai une certification ISO 9001  mon nom ce qui me donne le droit de travailler avec toutes les socits certifies ISO 9001 aussi

Les vraies normes , s'interdisent d'imposer quoique ce soit except une clart dans le communication et une transparence de mthodologie

J'ai aussi une certif EDI mais c'est comme toutes les normes mondiales , elle se ressemblent toutes, une fois que tu en as une.....

vous etes trop object maniacs pour moi. Si vous postulez chez moi un jour, il faudra surveiller a...

PseudoCode : okay la pizza n'est pas obligatoire : tu peux prfrer le chocolat chaud  ::):  par contre je suis clibataire et il m'arrive de faire 90h/semaine
Aurais tu une ralisation visible ? une spec ou des copies d'cran d'un projet dont tu t'es occup ?
Es tu mathmatiques ou itratif ?
Un rsum ? mme si ce n'est qu'un concept , a m'intresse ici ou en MP

----------


## Florian Goo

> Ici, il est plutt question de permettre aux gens qui le souhaitent d'indiquer ce qui,  leurs yeux, ne va pas "comme il faut" en C++...


Bien parl  :;): .

Pour en revenir au sujet initial, voici un dfaut du C++ qui m'a un peu gn il y a quelques temps :
J'ai eu besoin, dans un projet, de dclarer un ensemble de deux-cents types distincts. Tous ces types tant trs similaires, il s'agit en fait de typedefs d'instances de templates (il n'y a que 5 templates de classe  la base, donc le code ne compte aucune redondance).
Le problme, c'est que ces deux-cent types sont pour la plupart dpendants les uns des autres. Le diagramme de dpendances est un vrai sac de nud ! Des dpendances cycliques  la pelle

Lorsque deux classes (A et B) sont dpendantes l'une de l'autre, c'est pas bien compliqu : une dclaration anticipe de B avant la dfinition de A et c'est rgl.

A.hpp


```

```

B.hpp


```

```

A.cpp


```

```

B.cpp


```

```

Le hic, c'est qu'il est impossible de faire une dclaration anticipe d'un typedef. Du coup, j'ai t oblig d'utiliser l'idiome pimpl pour rsoudre les dpendances cycliques. Heureusement, le prprocesseur m'a permis d'liminer toute redondance dans le code, mais c'est quand mme beaucoup d'efforts pour rsoudre quelque chose qui ne fait pas partie de la problmatique principale du projet.

----------


## alexis b

> vous etes trop object maniacs


En c++, je ne fais pratiquement que de la programmation oriente objet, et j'ai justement dcouvert  quel point il tait le langage idal.

----------


## pseudocode

> Comme je l'ai dj dit, c'est malheureusement le prix  payer pour garantir la compatibilit maximale.
> 
> Ce n'est pas prs de changer, il faut donc "faire avec" et, surtout, cette permissivit est parfois indispensable pour certains projets


La question c'est "a-t-on vraiment besoin de garantir la compatibilit _ad vitam eternam_ ?". Je pense que la priode de transition C / C++ (only) a t assez longue.  ::D:  

Pour moi, il est temps soit de mettre en dsutude certaines pratiques du mixing C/C++, soit au contraire d' "objectifier" la pratique du C  l'intrieur du C++. 

Je finis par me demander si l'apparente complexit du C++ est lie  sa puissance ou si elle est "le prix a payer" pour garantir la compatibilit.  ::koi:: 





> PseudoCode : okay la pizza n'est pas obligatoire : tu peux prfrer le chocolat chaud  par contre je suis clibataire et il m'arrive de faire 90h/semaine


C'est pas moi qui ai parl de pizza. Y a erreur sur la personne je pense.

----------


## Florian Goo

> La question c'est "a-t-on vraiment besoin de garantir la compatibilit _ad vitam eternam_ ?". Je pense que la priode de transition C / C++ (only) a t assez longue.


Je rverais que les membres du comit tirent les mmes conclusions !
Je rverais que les rtrocompatibilits provenant du C (le typage faible des types primitifs, NULL, les casts  la C et j'en passe) soient mises  la trappe et que l'utilisation de code C ou legacy doive tre explicite  coups de  extern "C"  ou encore  extern "C++98" .

----------


## koala01

> La question c'est "a-t-on vraiment besoin de garantir la compatibilit _ad vitam eternam_ ?". Je pense que la priode de transition C / C++ (only) a t assez longue.


Je ne suis pas sur qu'il faille parler de "transition".

Aprs tout, la compatibilit va plus loin que le simple fait de permettre l'utilisation de bibliothques externes qui pourraient,  moindre frais, tre "bindes" en C++

Il s'agit, ni plus ni moins, de permettre l'interfaage de projet volumineux crits en C avec un langage plus "haut niveau".

Et tant que des dveloppements se feront en C, le besoin d'interfaage restera prsent  :;): 



> Pour moi, il est temps soit de mettre en dsutude certaines pratiques du mixing C/C++, soit au contraire d' "objectifier" la pratique du C  l'intrieur du C++.





> Je finis par me demander si l'apparente complexit du C++ est lie  sa puissance ou si elle est "le prix a payer" pour garantir la compatibilit.


L'apparente complexit de C++ est,  mon sens, beaucoup plus due au fait que c'est un langage multi paradigme qu' ce qui garanti la compatibilit avec C:

Le se fait de pouvoir dcider de travailler selon trois paradigmes distincts, alors que d'autres langages ne donnent pas cette possibilit de choix, suffit dj  provoquer une certaine complexit.

Et ca, c'est le prix  payer pour pouvoir apporter des solutions plus particulires  des problmes particuliers  :;): 

Je considre en effet,  l'instar de nombreux C++istes, que l'orient objet ne rsout pas tous les problmes, et qu'une approche multi paradigme permet facilement de contourner les problmes propres  chacun d'eux.

----------


## bioinfornatics

pour rpondre a koala01, la langage D est multi paradigme un peu plus que le C++ notamment par l'intgration native des delegate et plein d'autres choses et il est pourtant moins complexe.
Pour moi ayant travailler pas mal en C++ un de ses grand dfaut sont les messages d'erreur et ceux avec n'importe quelle compilateur c++. A force on s'y fait et on voit ou est le problme, cela reste un gros soucis.

----------


## koala01

> Toutefois, je pense que la programmation oriente objet c'est la programmation moderne et que c'est toujours ce qu'il faut privilgier.
> 
> Sinon vous serez un programmeur un peu dpass par l'volution...


Je penses, au contraire, que c'est avec des raisonnements si dfinitifs que tu risques de te trouver assez rapidement dpass par l'volution.

Comprenons nous bien: le paradigme orient objet prsente un grand nombre d'avantages, nous sommes tous d'accord l dessus.

Mais il prsente galement un certain nombre de faiblesses qui, comme c'est trange, peuvent tre contournes grce aux paradigmes procdural et gnrique.

C++ a l'norme avantage d'intgrer parfaitement ces trois paradigmes, alors, mlange les, enlace les jusqu' plus soif. Cela t'ouvrira des perspectives que tu ne pourrais imaginer en restant bloqu sur l'orient objet  :;):

----------


## Invit

> Totalement faux : avant sa normalisation, on comptait quasiment autant d'implmentations du langage que de plateformes.


Florian, j'ai le double ton ge. L'poque dont tu parles , je faisais du C 18h/j sur compilos unix Dos, cross compiler intel->6809 et deux sur Atari St.  
soit une 10zaine de compilateurs.

La norme tait trs "normale" K&R pb:mmoire video  , codage des entiers HSB LSB intel contre motorola
Mais tout a tait hors norme.  En 10 ans de C, j'ai fini par comprendre la subtilit , les limites

La portabilit n'a jamais t parfaite , les #ifdef #else servaient  a souvent et marchaient parfaitement 

Dsol si j'ai exagr mais , votre direction "philosophique" ne correspond pas  mon vcu pourtant trs orient c/c++ et trs international

Vous etes fach avec C mais si vous devez choisir entre un projet sur lanceur soyouz et le C++ (vous savez pourquoi je dis a..) vous renoncerez au projet soyouz ? ariane ? plutot que de vous abaisser au C ?

Quand je suis parti programmer ailleurs, lducation nationale faisait une fixation sur Pascal et ce "dtail" m'a fait quitter la fac !!!!   
Maintenant les jeunes diploms ne touchent plus  linux ! !   je comprends mal la France , ses choix

"philosophie des langages  "

----------


## hegros

> L'article prsente les dfauts en deux parties. Parmi ceux qui gnent l'auteur, on trouve: 
> 
>  Le temps de compilation et la gestion des dpendances
>  La bibliothque standard, qu'il juge rduite.
>  Le manque de rflexivit et la dduction des types
>  Les messages d'erreurs des templates
>  Le support de l'internationalisation sur la bibliothque standard


1/ Pas d'accord sur le temps de compilation et d'accord avec la gestion des dpendances. D'une part parce que bien que certains programment ncessitent prs de 24H pour compiler (KDE ? Gnome ? Seven ?) cela me semble normal et il serait difficile de faire mieux avec un gain important avec autre chose. Et d'autre part, la gestion des dpendances je la trouve lourde probablement  cause du manque d'outil de fichiers qu'il faut trimballer d au mode un fichier de dclaration et un fichier d'implmentation.

2/D'accord, l'exemple le plus frappant est sur la couche UI et accs aux donnes (SGBD par exemple, pas un simple fichier texte) il n'y a toujours rien de standardis  ce que je sache.

3/Plutt d'accord, d'ailleurs je me demande si le c++ est un langage  typage fort ou qu'il n'existerait justement pas un niveau typage trs fort lorsqu'il est possible de faire de la rflexivit, de l'infrence ou autre chose de plus avanc concernant la gestion des types de donnes (comme la srialisation/dsrialisation de type en xml par exemple)

4/Plutt d'accord, n'tant pas un praticien assidu en C++ pour les rares occasions o j'ai utilis ou repris des templates les messages d'erreurs ne sont pas forcment explicite. J'aurai tendance  vouloir les isoler dans un projet sparemment avec en sortie un composant comme une lib ou une dll rien que pour isoler les messages erreurs  ::aie:: 

5/Pas d'accord. Par rapport  ce qui existe autour comme langage le c++ doit rest dans la moyenne. Les moulinettes maisons pour l'internationalisation marche assez bien aussi.




> Parmi les dfauts souvent points du doigt et qui ne le gnent pas, il cite :
> 
>  La gestion et la corruption de la mmoire
>  La gestion du multitche
>  Le support des chaines de caractres
>  Les exceptions
>  STL, Boost et les templates en gnral


1/Cela est un peu gnant
2/Cela n'est pas gnant
3/Pour l'internationalisation oui cela pourrait tre gnant
4/Cela n'est pas gnant plus que cela.
5/Cela ne me gne pas ce sont des composants trs riche de ce que l'on peux attendre d'un framework




> Et pour vous, quel est le dfaut le plus gnant du C++ ?


Un aspect mythique et mystique avec le C  :;): 

Ensuite 1/une bibliothque standard trop rduite 2/Une utilisation abusive ou centrale du pr-processeur 3/La sparation entre fichier d'interface et d'implmentation 4/ Un manque dans la gestion des types 5/un manque de scurit excution et mmoire

----------


## Invit

> 1/une bibliothque standard trop rduite 2/Une utilisation abusive ou centrale du pr-processeur 3/La sparation entre fichier d'interface et d'implmentation 4/ Un manque dans la gestion des types 5/un manque de scurit excution et mmoire


le preprocesseur tait un enfer sous MFC
Pourtant sous audacity , le prprocesseur est minimal 

Donc  ce stade plus concret , si on ne dfinit pas un ensemble de projets open-source de rfrence, les arguments vont de oui  non sans prvenir !

J'ai codeBlocks et visualStudio installs.  
Y-a-til un projet qu'on peut downloader pour illustrer ?

----------


## hegros

> le preprocesseur tait un enfer sous MFC
> Pourtant sous audacity , le prprocesseur est minimal 
> 
> Donc  ce stade plus concret , si on ne dfinit pas un ensemble de projets open-source de rfrence, les arguments vont de oui  non sans prvenir !
> 
> J'ai codeBlocks et visualStudio installs.  
> Y-a-til un projet qu'on peut downloader pour illustrer ?


Quel critres et quelle valuation  chacun pour mesurer la non-qualit du pr processeur ? C'tait un enfer sous quel aspect ?

Ma remarque sur le pr-processeur c'est plutt parce qu'il me semble d'une part que les templates l'utilisent tout le temps et d'autres part que la stl soit fonde sur les templates. C'est l plus un dfaut d'architecture de bibliothque qu'un dfaut de performances.

Il faut des critres de rfrence avant de choisir des projets  comparer pourquoi ne pas prendre un arbre qualimtrique ISO c'est plutt un change sur les +/- du langage il doit exister quelques sources de comparaison sur le pr-processeur par langage ou par environnement de dveloppement

----------


## Invit

> Quel critres et quelle valuation  chacun pour mesurer la non-qualit du pr processeur ? C'tait un enfer sous quel aspect ?
> 
> Ma remarque sur le pr-processeur c'est plutt parce qu'il me semble d'une part que les templates l'utilisent tout le temps et d'autres part que la stl soit fonde sur les templates. C'est l plus un dfaut d'architecture de bibliothque qu'un dfaut de performances.
> 
> Il faut des critres de rfrence avant de choisir des projets  comparer pourquoi ne pas prendre un arbre qualimtrique ISO c'est plutt un change sur les +/- du langage il doit exister quelques sources de comparaison sur le pr-processeur par langage ou par environnement de dveloppement


MFC 6 dcrivait les controles de forms dans des constantes. L'ancien activeX ncessitait un clsID, les proprits de controles et les events stocks dans un .hpp prcompil. Celui-ci devenait norme et instable (plusieurs dizaines de mb)

ok , une urgence en C# qui vient de tomber , je vais me rarfier sur les vieux langages mystiques  ::):  (15 ans de boulot pour demain matin ) bonne chance

----------


## pseudocode

> Le se fait de pouvoir dcider de travailler selon trois paradigmes distincts, alors que d'autres langages ne donnent pas cette possibilit de choix, suffit dj  provoquer une certaine complexit.
> 
> Et ca, c'est le prix  payer pour pouvoir apporter des solutions plus particulires  des problmes particuliers 
> 
> Je considre en effet,  l'instar de nombreux C++istes, que l'orient objet ne rsout pas tous les problmes, et qu'une approche multi paradigme permet facilement de contourner les problmes propres  chacun d'eux.


100% d'accord avec cette dernire phrase. Cependant le multi paradigme n'implique pas forcment de pouvoir mlanger deux langages dans un meme bloc de code, voir dans une meme ligne. Un barrire, au moins syntaxique comme le suggre Florian Goo, me paraitrait dj un mieux. D'ailleurs, je vois de moins en moins d'encart assembleur dans les code C/C++, certainement a cause de cela.

----------


## koala01

> 100% d'accord avec cette dernire phrase. Cependant le multi paradigme n'implique pas forcment de pouvoir mlanger deux langages dans un meme bloc de code, voir dans une meme ligne. Un barrire, au moins syntaxique comme le suggre Florian Goo, me paraitrait dj un mieux. D'ailleurs, je vois de moins en moins d'encart assembleur dans les code C/C++, certainement a cause de cela.


Je n'ai pas parl de mlanger deux langages, mais deux paradigmes, et ca, ca se fait pour le moins rgulirement:


```

```

Et ce ne sont que des exemples vite faits qui facilitent normment les choses par rapport  l'OO "pur et dur"  :;):

----------


## pseudocode

> Et ce ne sont que des exemples vite faits qui facilitent normment les choses par rapport  l'OO "pur et dur"


C'est clair que c'est pratique. Quand je pense qu'en Java c'est la galre pour qu'une mthode retourne deux "int".  ::calim2::  

Aprs, je suis prt a sacrifier un peu de cette puissance au profit d'une meilleure homognit du code. En particulier dans un contexte industriel, o la maintenance sur le long terme est tout aussi importante (voir plus) que la concision du code source.

----------


## koala01

> C'est clair que c'est pratique. Quand je pense qu'en Java c'est la galre pour qu'une mthode retourne deux "int".


Il n'y a aucune fonction qui retourne deux int ici, il y a un oprateur qui compare le rsultat d'une fonction membre particulire pour dterminer si deux instances sont gales.



> Aprs, je suis prt a sacrifier un peu de cette puissance au profit d'une meilleure homognit du code. En particulier dans un contexte industriel, o la maintenance sur le long terme est tout aussi importante (voir plus) que la concision du code source.


Cela veut-il dire que tu considre que


```
if(instance1.equal(instance2))
```

sera plus facilement maintenable que


```
if(instance1==instance2)
```

 ::question:: 

A partir du moment o l'on est d'accord sur la smantique des oprateurs, je ne vois pas vraiment pourquoi ils s'avreraient moins maintenable  ::P: 

Et puis, un code proche de celui que je propose (surtout pour l'oprateur ==) est il vraiment si peu homogne, sachant que cela permet la rflexibilit de l'oprateur ( A==B est identique  B==A, mme si une conversion implicite a lieu  ::D: )

----------


## Florian Goo

> Vous etes fach avec C mais si vous devez choisir entre un projet sur lanceur soyouz et le C++ (vous savez pourquoi je dis a..) vous renoncerez au projet soyouz ? ariane ? plutot que de vous abaisser au C ?


Non non, je ne suis pas du tout fch avec le C !
Certes, la dernire fois que j'ai eu l'occasion de coder en C remonte  2 ou 3 ans, mais j'ai ralis quelques projets fort sympathiques comprenant l'criture de firmwares en C sur microcontrleurs. Je dois mme reconnatre que a me manque un peu.

La seule chose avec laquelle je suis fch, c'est l'amalgame C/C++ que certains membres prnent, selon moi,  tort.




> (vous savez pourquoi je dis a..)


Dsol, je n'ai pas saisi !




> Quand je suis parti programmer ailleurs, lducation nationale faisait une fixation sur Pascal et ce "dtail" m'a fait quitter la fac !!!!   
> Maintenant les jeunes diploms ne touchent plus  linux ! !   je comprends mal la France , ses choix


J'cris ce message depuis ma distribution Linux prfre  :;): .
Je sors d'une cole d'ingnieurs o l'initiation  la programmation se fait en C, avec des TP raliss sous Linux. Je pense que la fixation sur le Pascal n'est plus d'actualit.

En revanche, je rejoignais totalement ton propos sur le sujet  Les dveloppeurs peuvent-ils faire de bons managers ? . La vision de la France sur ce plan est vraiment absurde.

Sur le coup (Linux, Pascal et le principe de Peter) tu ne peux pas m'associer  ce que tu perois de la philosophie franaise  :;): .

----------


## pseudocode

> Il n'y a aucune fonction qui retourne deux int ici, il y a un oprateur qui compare le rsultat d'une fonction membre particulire pour dterminer si deux instances sont gales.


Yes. J'ai beau pas tre un virtuose du C++, j'avais remarqu.  ::aie:: 

Ma remarque tait pour accentuer le fait que le mono-paradigme OO de Java empche de retourner l'quivalent d'une "struct" mais impose de retourner une instance d'objet. Ce qui est tout de meme trs gnant d'un point de vue conceptuel, car il n'y a pas de raison smantique de dfinir une classe pour rsoudre ce qui n'est qu'un problme de code.  :;): 




> Cela veut-il dire que tu considre que
> 
> 
> ```
> if(instance1.equal(instance2))
> ```
> 
> sera plus facilement maintenable que
> 
> ...


C'est justement parce qu'il n'y a pas de moyen d'tre d'accord sur la smantique des oprateurs  moins de faire une revue exhaustive du code source. A partir du moment o il est permis de redfinir un oprateur, voir un mot cl du langage, il n'y a pas possibilit de prsupposer de ce que fait une simple comparaison.

Pour moi, la premire forme (.equal())  peut renvoyer true, false, 0, -1, "hello world", voir lever une exception, afficher du texte, ou faire un exit(). Bref tout ce que peut faire un appel de mthode.

Mais en fait, la deuxime aussi. Sauf que c'est moins visible au premier coup d'oeil. Et donc le risque est plus grand de faire l'impasse sur toutes ces possibilits, et de se contenter de croire que le "==" est un oprateur du langage qui compare deux valeurs et renvoie un boolen.

Dans un contexte de dev projet, je prfre un langage qui me permet facilement de savoir ce que peut faire (ou ne pas faire) une ligne de code. Dans un contexte de dev perso, videmment ca s'applique moins, tant donn que j'ai naturellement tendance a me faire confiance.  ::aie::

----------


## cyrianox

J'ai toujours ador la syntaxe C/C++ : propre, concise et prcise.
Par contre, pour ceux qui codent dans plusieurs langage, revenir au C/C++ aprs quelques mois d'autre chose, ce n'est pas vident.. (surtout quand on s'habitue au confort des editeurs qui affichent en temps rel les erreurs possibles).

----------


## hiura

Pour:
Une rfrence par jour loigne du docteur.
Le polymorphisme est trs subtile et prcis. (Pas comme JAVA, voir discussion sur virtual plus haut, hritage multiple.)
La S(T)L est trs bien conue (heureusement me diriez vous!) : pas d'interdpendances dans TOUS les sens comme avec l'API JAVA.
Le mot clef const. (Pas besoin de se farcir deux version (mutable/immutable) de chaque outils.)
La sparation .h(pp)/.c(pp) qui permet d'avoir l'API publique  port de main. (Encore une critique pour JAVA ou on se retrouve avec des fichiers de plusieurs centaines de lignes desquels on doit extraire les infos)

Neutre: (voire remarque de koala (dsol si j'corche, les iPod c'est pas pratique pour tout) ; en rsum ce n'est pas C++ qu'il faut blmer mais les dev.)
L'enseignement mdiocre voire absent ! Quand j'ai appris que les ingnieurs "computer science" de l'EPFL n'avaient pas de cours sur le C++ je suis tomb des nues! Par contre on est bombard de JAVA  ::?: 

Contre:
La S(T)L est petite.
[discutable]Pas de norme graphique -> trop de maux pour faire du portable. Mais ceci est discutable pour deux raisons :
1) Est-ce au langage de s'occuper de a ? 
2) Veut-on se retrouver avec un sosie de JAVA ?

----------


## pseudocode

> Pour:
> Une rfrence par jour loigne du docteur.
> Le polymorphisme est trs subtile et prcis. (Pas comme JAVA, voir discussion sur virtual plus haut, hritage multiple.)
> La S(T)L est trs bien conue (heureusement me diriez vous!) : pas d'interdpendances dans TOUS les sens comme avec l'API JAVA.
> Le mot clef const. (Pas besoin de se farcir deux version (mutable/immutable) de chaque outils.)
> La sparation .h(pp)/.c(pp) qui permet d'avoir l'API publique  port de main. (Encore une critique pour JAVA ou on se retrouve avec des fichiers de plusieurs centaines de lignes desquels on doit extraire les infos)


hum... Meme si Java a des dfauts, faut quand meme pas en rajouter. Critiquer autant la librairie standard de Java, c'est un peu "too much", sachant que l'une des premires choses qu'on fait gnralement quand on dbute un projet d'envergure en C++ c'est de se choisir une bonne librairie additionnelle.  ::P: 

Ceci dit, c'est vrai que la prcision qu'on peut dfinir sur les structures de donnes est un gros + du C++  ::ccool:: . Le prix a payer tant une syntaxe souvent complique, avec moult symboles et mots-cls.

----------


## divxdede

> a- Parfois j'ai l'impression que les gens critiquent les vlos parce qu'ils ne sont pas adapts aux escaliers et que du coup il faudrait toujours se balader  pieds.
> Oui, il y a aura toujours des garnements qui utiliseront de travers ce qu'ont leur met  disposition. Reste que c'est bien plus agrable  utiliser que les interfaces SAXPYiennes des BLAS, ou mme de ce que l'on trouvera en Java.
> 
> b- Bien au contraire. Je me permets de copier-coller de la prose que j'avais crite pour un doc de qualit:
> 
> 
> Un petit exemple qui illustre cela : les listes et les listes tries. Quelqu'un d'un peu naf pourra croire qu'il suffit de driver une classe liste pour dfinir une classe listetrie aprs avoir redfini la fonction d'insertion pour insrer au bon endroit. Sauf que cela sabotera compltement le contrat de la liste.
> 
> 
> Accessoirement, la liaison tardive n'est qu'un des aspects du polymorphisme (d'inclusion -- mine de rien, le C++ en supporte 3 autres). virtual n'est pas ncessaire pour _utiliser en place de_.



Je ne suis pas d'accord.
Soit on autorise la surcharge d'une mthode par une classe fille et dans ce cas on met en jeu la liaison tardive (polymorphisme), soit on empeche la surcharge de la mthode.
Mais rendre une mthode surchargeable par une classe fille mais executer le code sous-jacent selon le type connu statiquement de ton objet, ca reste dans mon esprit une hrsie. Or en C++ une mthode est toujours suchargeable par une classe fille (il n'y a pas de possibilit d'indiquer qu'une mthode est "final").

Je comprends les critres qui on pousss  ce genre de choix (une mthode sans virtual ne prends pas de cout d'execution a cause de la vTable) mais j'estime qu'il manque une notion derrire de concept de "virtual", celle de pouvoir interdir la surcharge d'une mthode par une classe fille.

----------


## jblecanard

> Je comprends les critres qui on pousss  ce genre de choix (une mthode sans virtual ne prends pas de cout d'execution a cause de la vTable) mais j'estime qu'il manque une notion derrire de concept de "virtual", celle de pouvoir interdir la surcharge d'une mthode par une classe fille.


Je suis compltement d'accord, c'est un petit truc en plus qui ferait plaisir.

----------


## gl

> Or en C++ une mthode est toujours suchargeable par une classe fille (il n'y a pas de possibilit d'indiquer qu'une mthode est "final").


La prsence du mot-cl final et l'interdiction de surcharger un mthode non virtuel n'ont pas rellement de rapport.

Le mot cl final est juste le pendant du mot cl virtual dans des langages ayant fait le choix du virtuel par dfaut.
L'interdiction de surcharger des mthodes non virtuelles dans une classe fille peut se faire sans la prsence de final.

Le seul intrt qu'il pourrait y avoir en C++  introduire le mot cl final serait d'empcher la propagation de la virtualit d'une mthode en dessous d'un certain niveau de la chane d'hritage. Je ne suis pas certain de l'intrt de la chose (personnellement, je n'ai jamais rencontr se besoin. Il est possible que d'autres si).




> mais j'estime qu'il manque une notion derrire de concept de "virtual", celle de pouvoir interdire la surcharge d'une mthode par une classe fille.


Je laisse de ct le cas particulier du destructeur qui est plus problmatique.

Est-il vraiment souhaitable de l'interdire ? N'y a-t-il absolument aucun cas o la surcharge dans une classe fille d'une mthode non virtuelle serait lgitime ?

Qu'un avertissement soit mis par le compilateur dans ce cas est vraisemblablement une bonne chose, mais de l  interdire compltement la construction, je me demande si ce n'est pas une solution trop extrme.



PS: Les questions ci-dessus sont de vrais questions, pas un simple effet de style. Car certes, je n'ai jamais rencontr le besoin de surcharger une fonction non virtuelle et a me "choque" de songer  le faire. Mais jugeant essentiellement au vue de mon exprience, il est possible que je passe  ct de quelque chose.

----------


## Invit

C++ est un langage que je trouve trs bien fait et qui respecte  la lettre ses principes de bases (on ne paye pas pour ce qu'on utilise pas).

Les problmes :
- pas de systme de module, inclusion textuelle pas toujours pertinente

- trs dur  parser



> C++ isn't hard to parse because it requires arbitrary lookahead; that's an easy problem to solve. It's hard to parse because a particular sequence of tokens can produce multiple totally different parse trees, depending on what some of the symbols are declared as. Even worse, many of those symbols aren't known at parse time, because they aren't declared yet. So it has to be parsed into some indeterminate state that gets "fixed" later. 
> 
> This issue makes it impossible to correctly parse C++ code without building most of a C++ compiler front end, including all the hard stuff. - Walter Bright


- productivit mauvaise (a se discute videmment)

----------


## S(.)B

Je suis tout  fait d'accord avec pseudocode pour la surcharge de l'oprateur == !




> La sparation .h(pp)/.c(pp) qui permet d'avoir l'API publique  port de main. (Encore une critique pour JAVA ou on se retrouve avec des fichiers de plusieurs centaines de lignes desquels on doit extraire les infos)


Par contre pour a je ne suis pas d'accord, mais pas du tout. Car dj si tu n'as  ta disposition que le code source .java tu peux le transformer en .h avec un petit "collapse all" de ton IDE. Et "normalement" (dans un monde o tout le monde a pris le temps de documenter son code) tu as la petite Javadoc associe qui va bien  :;): 

Aprs je vous rejoins pour les cours de C++, j'aurais ador faire des TP de C++ avec QT par exemple, malheureusement on en n'a mme pas entendu parl en cours...

----------


## gl

> C'est justement parce qu'il n'y a pas de moyen d'tre d'accord sur la smantique des oprateurs  moins de faire une revue exhaustive du code source. A partir du moment o il est permis de redfinir un oprateur, voir un mot cl du langage, il n'y a pas possibilit de prsupposer de ce que fait une simple comparaison.
> 
> Pour moi, la premire forme (.equal())  peut renvoyer true, false, 0, -1, "hello world", voir lever une exception, afficher du texte, ou faire un exit(). Bref tout ce que peut faire un appel de mthode.
> 
> Mais en fait, la deuxime aussi. Sauf que c'est moins visible au premier coup d'oeil. Et donc le risque est plus grand de faire l'impasse sur toutes ces possibilits, et de se contenter de croire que le "==" est un oprateur du langage qui compare deux valeurs et renvoie un boolen.


Mais ce n'est ni plus ni moins que le mme problme que celui du choix des noms (de mthodes, variables).

Si tu tombes sur une mthode equal() tu t'attends  ce qu'elle fasse un test d'galit. Si finalement elle fait tout  fait autre chose, tu vas tre surpris et estimer ( juste titre  mon avis) que celui qui l'a faite est un imbcile.
C'est pareil pour la surcharge d'un oprateur, si l'oprateur surcharg n'a pas une smantique logique et s'loigne du fonctionnement des oprateurs de base c'est que le choix de cet oprateur n'tait clairement pas bon, mais cela ne remet pas,  mon sens, en cause la surcharge des oprateurs.

Et  titre personnel, je trouve bien plus logique d'utiliser les oprateurs de comparaison pour faire une comparaison, l'oprateur d'affectation pour faire une affectation, etc. que d'appeler une fonction quelconque.

----------


## gl

> Par contre pour a je ne suis pas d'accord, mais pas du tout. Car dj si tu n'as  ta disposition que le code source .java tu peux le transformer en .h avec un petit "collapse all" de ton IDE. Et "normalement" (dans un monde o tout le monde a pris le temps de documenter son code) tu as la petite Javadoc associe qui va bien


C'est un petit peu plus compliquer que a.

Avec collapse all, tu vas voir tout ce qu'il y a dans ton implmentation. Alors que dans le .h tu ne peux exposer qu'une partie de ce contenu, ce qui permet d'organiser les header en fonction du public cible et notamment d'avoir des .h ne comportant que l'interface publique.

----------


## Invit

Hello world  ::):  je vous lis pendant la pause caf. J'ai sans doute mis suffisamment le souk dans vos ttes bien faites. Je suis vraisemblablement plus attach  l'aspect business...  Certains projets compltement pourris dont plus personne ne veut peuvent tre des opportunits fantastiques, on arrive sur un code patch de partout , plein de rustines douteuses, de bugs irrattrapables que les users contournent quotidiennement.
C'est pourquoi je n'ai aucune svrit sur ce qu'est devenu le couple C/C++. Ca me rappelle les fois ou des quipes de hautes vole ont fait "ce qu'elle pouvaient". 
Ca mrite des critiques mais a fait rflchir sur les langages plus rcents et la reditribution des cartes qu'ils ont permis aux diteurs. Eux par contre, ont continu avec C(++) ce qui leur a permis de ne pas tre concurrencs par les autres.  Dans ces cas l : plus c'est pourri, plus c'est intressant  ::):

----------


## S(.)B

> Mais ce n'est ni plus ni moins que le mme problme que celui du choix des noms (de mthodes, variables).
> 
> Si tu tombes sur une mthode equal() tu t'attends  ce qu'elle fasse un test d'galit. Si finalement elle fait tout  fait autre chose, tu vas tre surpris et estimer ( juste titre  mon avis) que celui qui l'a faite est un imbcile.
> C'est pareil pour la surcharge d'un oprateur, si l'oprateur surcharg n'a pas une smantique logique et s'loigne du fonctionnement des oprateurs de base c'est que le choix de cet oprateur n'tait clairement pas bon, mais cela ne remet pas,  mon sens, en cause la surcharge des oprateurs.
> 
> Et  titre personnel, je trouve bien plus logique d'utiliser les oprateurs de comparaison pour faire une comparaison, l'oprateur d'affectation pour faire une affectation, etc. que d'appeler une fonction quelconque.


Oui je suis d'accord mais personnellement je fais ( tort ?) une confiance aveugle aux oprateurs de base, et donc si jamais il y a un problme dans mon code dont je ne trouve pas la cause je ne suis pas sr que je souponnerai le == surcharg que j'utilise. Alors qu'avec equal() tu vois bien que c'est une mthode et j'en viendrai plus facilement  souponner le code de cette mthode.

Aprs c'est sr que si les oprateurs surchargs ne comportent jamais de bug, l je te suis totalement d'accord avec toi, malheureusement...

----------


## pseudocode

> Et  titre personnel, je trouve bien plus logique d'utiliser les oprateurs de comparaison pour faire une comparaison, l'oprateur d'affectation pour faire une affectation, etc. que d'appeler une fonction quelconque.


Je ne remet pas en cause la possibilit de pouvoir dfinir un nouvel oprateur sur une classe. Ce qui me drange c'est de pouvoir redfinir un oprateur de base du langage, qui  donc une signification connue par tous.

Tout comme redfinir les mots cls "for", "if", "return" ou les symboles "*", "->" ou "&" me semble certes trs puissant, mais aussi trs sujet  risque.

----------


## atttchoum

> Et pour vous, quel est le dfaut le plus gnant du C++ ?


d'abord une bibliothque standard vraiment trop rduite mais surtout une documentation tout simplement misrable pour une librairie qui sera utilis par tout les dveloppeur c++ a un moment ou  un autre.

sinon l'ajout de librairies extrieurs est parfois vraiment complexe.

----------


## Davidbrcz

> Je ne remet pas en cause la possibilit de pouvoir dfinir un nouvel oprateur sur une classe. Ce qui me drange c'est de pouvoir redfinir un oprateur de base du langage, qui  donc une signification connue par tous.
> 
> Tout comme redfinir les mots cls "for", "if", "return" ou les symboles "*", "->" ou "&" me semble certes trs puissant, mais aussi trs sujet  risque.


Oula !
Il est impossible de redefinir les operateurs sur les types primitifs ou den creer de nouveau. Si tu creer un operateur == pour une classe A, tu ne vas pas magiquement en avoir un pour une classe B. 

Par ailleurs, sur == vs equal, a partir du moment ou tu ne manipule pas un type primitif, tu sais que == est une fonction (il ny a aucune ambiguite possible)




> une  documentation tout simplement misrable pour une librairie qui sera  utilis par tout les dveloppeur c++ a un moment ou  un autre.


Tu fais quoi de roguewave , SGI, MSDN (partie STL) ?

----------


## koala01

> Je ne remet pas en cause la possibilit de pouvoir dfinir un nouvel oprateur sur une classe. Ce qui me drange c'est de pouvoir redfinir un oprateur de base du langage, qui  donc une signification connue par tous.
> 
> Tout comme redfinir les mots cls "for", "if", "return" ou les symboles "*", "->" ou "&" me semble certes trs puissant, mais aussi trs sujet  risque.


Attention, quand mme...

Il est vrai que les oprateurs ont tous leur smantique propre, et peuvent tre regroups par "catgorie"

+,-,*,/,+=,-=,*=,/=, ++, -- oprateurs mathmatiques<,>,<=,>=,== oprateur de comparaison&,*,-> oprateurs d'accsCes oprateurs ne peuvent, de toute manire, tre appels que s'ils sont valablement dfinis pour un type particulier.

C'est au dveloppeur qui dcide de les dfinir de veiller  ce qu'ils gardent leur smantique propre  :;): 

l'toile (prise dans sa smantique d'oprateur d'accs) et la flche ne seront, par exemple, utiliss que dans le cadre d'une classe encapsulant une valeur  laquelle on souhaite accder  :;): 

La seule exception que je connaisse au principe de garder une smantique identique est celle de boost::serialize qui utilise l'oprateur & dans une smantique qui n'est pas habituelle.

Mais l'approche de cette bibliothque est sense et clairement documente, ce qui fait que, bien que l'esperluette ne soit pas utilise avec sa smantique habituelle, cela ne me pose pas de problme philosophique majeur  :;):

----------


## alexis b

> a partir du moment ou tu ne manipule pas un type primitif, tu sais que == est une fonction


C'est ce qui s'appelle, la surcharge des oprateurs ! Je l'utilise et c'est trs pratique  ::ccool:: .

----------


## jblecanard

> C'est ce qui s'appelle, la surcharge des oprateurs ! Je l'utilise et c'est trs pratique .


Toi tu n'as pas lu tous les posts  ::mouarf::

----------


## Invit

> C++ est un langage que je trouve trs bien fait et qui respecte  la lettre ses principes de bases (on ne paye pas pour ce qu'on utilise pas).
> 
> Les problmes :
> - pas de systme de module, inclusion textuelle pas toujours pertinente
> 
> - trs dur  parser
> 
> - productivit mauvaise (a se discute videmment)


J'aime bien ce message (cliquer la flche pour lire la citation)car il suggre beaucoup de situations sans les lister toutes...
Pour le parser, on arrive en C++  la mme situation que dans un code php/html/javascript car l'volution de ces deux technos a t historiquement voisine : impossible de rcrire les standards initiaux sans mettre la moiti du monde en panne !

le parallle s'arrte l car les effets de prcdence dcrits sont lis  la compilation alors que les interprteurs du monde web autorisent une infinit d'encapsulations. D'autre part il est assez incongru de faire un gnrateur de code compil dpendant du contexte,  moins d'embarquer un compilateur dans l'application.   Je suis particulirement confront  ce cas. Je dois embarquer un compilateur, hormis les problmes de droit (qui ne me laissent pas de choix sur le langage ), c'est une aventure technique trs particulire. Heureusement, je suis devenu (tardivement)fan des expressions rgulires!!

----------


## hiura

> hum... Meme si Java a des dfauts, faut quand meme pas en rajouter. Critiquer autant la librairie standard de Java, c'est un peu "too much", sachant que l'une des premires choses qu'on fait gnralement quand on dbute un projet d'envergure en C++ c'est de se choisir une bonne librairie additionnelle.


Ce n'est pas too much, pas avec ma petite histoire d'amour avec JAVA.  ::aie:: 

Bon c'est vrai que je suis un peu excessif des fois, raisons personnelles, blablabla, on s'en fiche! Mais quand je vois la difficult que j'ai eu  m'adapter  JAVA et son API pour un petit projet (j'abrge parce que c'est franchement pas passionnant, mais pour les curieux voici plus d'info) alors qu'avec le C++ j'aurais rencontrer moins de difficults. (Certains diront que c'est une question d'exprience. Je leur rpondrai que ce n'est pas tout  fait vrai, pour chaque langage de programmation il y a une faon de penser propre et celle du C++ est plus adapte  ma personne contrairement  celle de JAVA.)

Pour tre franc j'ai encore t gentil avec JAVA dans ces deux posts, si tu savais ce que j'en pensais rellement tu me brlerais peut-tre sur la place public!  ::aie::  (Mais a commence  tre hors topic, j'avoue.)




> Par contre pour a je ne suis pas d'accord, mais pas du tout. Car dj si tu n'as  ta disposition que le code source .java tu peux le transformer en .h avec un petit "collapse all" de ton IDE. Et "normalement" (dans un monde o tout le monde a pris le temps de documenter son code) tu as la petite Javadoc associe qui va bien


C'est sr que NetBeans, entre autre, est bien conu, mais que peut-il faire si tu as le code sur une feuille de papier ? Tu me diras que a arrive pas bien souvent mais quand a arrive t'es vraiment content d'avoir tes deux fichiers .h(pp)/.c(pp)! (Exemple :  ton examen)

Note que l'argument de la documentation n'est pas trs valide puisque en C++ (et de manire gnrale tout le temps) aussi tu dois documenter mais ce n'est en aucun cas une obligation du langage. Enfin bref.

----------


## hiura

Hum, et je peux rajouter quand mme un point noir au C++ :
Pas de import (au sens Objective-C du terme et non Java qui n'a pas la mme utilit).

(En Obj-C, il s'utilise comme include sauf que les anti-inclusion multiple ne sont plus ncessaire.)

----------


## koala01

> Note que l'argument de la documentation n'est pas trs valide puisque en C++ (et de manire gnrale tout le temps) aussi tu dois documenter mais ce n'est en aucun cas une obligation du langage. Enfin bref.


D'autant plus que, ds qu'il y a moyen de mettre des commentaires, il existe sans doute des outils capables d'en extraire tout ou partie pour crer une documentation  ::aie::  

Pensez, par exemple,  doxygen  ::D:

----------


## pseudocode

> Oula !
> Il est impossible de redefinir les operateurs sur les types primitifs ou den creer de nouveau. Si tu creer un operateur == pour une classe A, tu ne vas pas magiquement en avoir un pour une classe B.


Mme si B hrite de A ?




> a partir du moment ou tu ne manipule pas un type primitif, tu sais que == est une fonction (il ny a aucune ambiguite possible)


Tu veux dire que le compilateur gnre une erreur si je n'ai pas explicitement overrid l'oprateur ?





> C'est au dveloppeur qui dcide de les dfinir de veiller  ce qu'ils gardent leur smantique propre


C'est justement ma critique personnelle depuis le dbut. Je prfrerai que la smantique des oprateurs prsents "de base" soit inaltrable par le programmeur.

Mais bon, a force on va finir par croire que je suis un anti-cplusplussien, alors que j'aime plutt bien ce langage. Je le trouve juste trop "permissif" a mon gout pour l'utiliser dans un contexte industriel, sans prendre une liste (que je juste trop excessive) de prcautions.




> Pour tre franc j'ai encore t gentil avec JAVA dans ces deux posts, si tu savais ce que j'en pensais rellement tu me brlerais peut-tre sur la place public!


J'ai aussi des critiques a formuler sur Java, mais ce n'est pas le lieu.  ::D:

----------


## S(.)B

> C'est sr que NetBeans, entre autre, est bien conu, mais que peut-il faire si tu as le code sur une feuille de papier ? Tu me diras que a arrive pas bien souvent mais quand a arrive t'es vraiment content d'avoir tes deux fichiers .h(pp)/.c(pp)! (Exemple :  ton examen)
> 
> Note que l'argument de la documentation n'est pas trs valide puisque en C++ (et de manire gnrale tout le temps) aussi tu dois documenter mais ce n'est en aucun cas une obligation du langage. Enfin bref.


En fait pour la doc je voulais dire qu'en Java avec tous les IDE dignes de ce nom on peut regarder la doc d'une mthode ou autre sans pour autant ouvrir la classe correspondante, ce qui n'est par exemple pas possible ( ma connaissance) avec Code::Blocks (que je suis oblig d'utiliser) en C++.

Et sinon il faut brler les exams papiers en informatique !  ::evilred::  (enfin ceux o il faut juste pondre du code)

----------


## Pill_S

> C'est sr que NetBeans, entre autre, est bien conu, mais que peut-il faire si tu as le code sur une feuille de papier ? Tu me diras que a arrive pas bien souvent mais quand a arrive t'es vraiment content d'avoir tes deux fichiers .h(pp)/.c(pp)! (Exemple :  ton examen)
> 
> Note que l'argument de la documentation n'est pas trs valide puisque en C++ (et de manire gnrale tout le temps) aussi tu dois documenter mais ce n'est en aucun cas une obligation du langage. Enfin bref.


C'est quand mme formidable de voir le nombre de post qui se plaignent que les interfaces et les implmentations ne sont pas spares dans des fichiers distincts en java... Notez quand mme:

1) on n'a besoin de l'interface que pour des raisons de "documentation" (au sens large), c'est  dire pour comprendre comment utiliser telle ou telle objet... En java il y a la javadoc, trs rpandue et trs pratique, et bien plus claire qu'un fichier .h, sinon il y a les vues "outline" dans les diteur, qui permettent de filtrer les mthodes statiques et / ou non publiques...
2) il y a sinon la notion d'interface (mot rserv) qui reprsente quasiment l'quivalent d'un fichier .h, et qui sont galement trs utilises.
3) sinon pour c et c++, je ne ferai pas de commentaires, ces 2 technos tant assez obscures pour moi et pas trs "human friendly"

Mais par piti, arrtez de vous plaindre de l'absence des fichiers .h... pour moi c'est une abberration

----------


## koala01

> Mme si B hrite de A ?


Si B hrite de A, on peut, dcemment, estimer que la comparaison se fera de manire identique, quitte  ce qu'il y ait redfinition d'une des fonctions qui intervient dans le processus.

Autrement, c'est plutt du cot d'un problme de conception qu'il faudra se tourner  :;): 




> Tu veux dire que le compilateur gnre une erreur si je n'ai pas explicitement overrid l'oprateur ?


Exactement:


```

```

provoque l'erreur


```
main.cpp|10|error: no match for 'operator==' in 'c1 == c2'|
```




> C'est justement ma critique personnelle depuis le dbut. Je prfrerai que la smantique des oprateurs prsents "de base" soit inaltrable par le programmeur.


Il en va de mme pour les fonctions...

Si je nomme une fonction membre "equal" ou "less", l'utilisateur peut, dcemment, s'attendre  ce qu'elles effectuent une comparaison entre deux objets.

Si elles ont un autre effet, j'en reste le seul responsable, et c'est que j'ai mal choisi le nom de ma fonction  :;): 

Si je dcide, pour une raison qui m'est propre, de modifier la smantique d'un oprateur, il m'appartient de choisir effectivement de le faire ( ma charge de motiver et de documenter ma dcision) ou non  :;): 

Je ne vois pas pourquoi on appliquerait aux oprateurs des rgles diffrentes de celles que l'on applique aux fonctions  :;): 



> Mais bon, a force on va finir par croire que je suis un anti-cplusplussien, alors que j'aime plutt bien ce langage. Je le trouve juste trop "permissif" a mon gout pour l'utiliser dans un contexte industriel, sans prendre une liste (que je juste trop excessive) de prcautions.


Ce que tu appelle permissivit, j'aurais tendance  l'appeler libre arbitre.

Tu remarqueras que c'est encore une question de point de vue  ::D:

----------


## atttchoum

> Tu fais quoi de roguewave , SGI, MSDN (partie STL) ?


je trouve SGI et MSDN trs brouillon (enfin j'avoue que j'ai jamais t foutu de comprendre comment MSDN tait range ::aie:: ).
Quand  roguewave, je ne connaissais pas et je dcouvre en se moment mme ::D: .

----------


## koala01

> En fait pour la doc je voulais dire qu'en Java avec tous les IDE dignes de ce nom on peut regarder la doc d'une mthode ou autre sans pour autant ouvrir la classe correspondante, ce qui n'est par exemple pas possible ( ma connaissance) avec Code::Blocks (que je suis oblig d'utiliser) en C++.


Encore une fois, tu confonds les possibilits du langage avec celles des outils que tu utilises.

D'autres outils, comme Visual Studio ou Borland (aprs tout, il m'est dj suffisamment arriv de les dnigrer pour d'autres raisons pour pouvoir les encenser un peu  ::D: ) intgrent un systme d'aide des plus efficaces, et ce, depuis de nombreuses versions  ::D: 

On pourrait discuter de la politique suivie par les dev de code::block sur le sujet, mais ce n'est pas le lieu  :;):

----------


## jblecanard

> 2) il y a sinon la notion d'interface (mot rserv) qui reprsente quasiment l'quivalent d'un fichier .h.


Absolument pas. En java, un seul objet peut adhrer  plusieurs interfaces (c'est l'intrt d'ailleurs). Pour faire a en C++, c'est l'hritage multiple et toutes les difficults qui viennent avec (on a d'autres techniques heureusement). L'interface au sens java et le header en C++ n'ont vraiment rien  voir.

Un petit rappel :
- Il y a doxygen qui fait aussi bien que javadoc pour c++, et c'est gratuit.
- Je prfre largement maintenir de la doc dans un .h et avoir mon implmentation ailleurs que devoir m'occuper en permanence d'un mlange des deux.
- Rien n'empche de tout implmenter dans ses headers, la sparation est une bonne pratique et en rien une obligation. Ne pas le faire relve de l'hrsie mais c'est possible.

----------


## ml17330

J'ai utilis C++ comme du C pour dvelopper des logiciels financiers  une poque o le choix tait reduit.
Aujourd'hui je ne dveloppe plus que des jeux vido et j'utilise pour a des outils bien plus adapts ::lol::

----------


## JeitEmgie

> C'est quand mme formidable de voir le nombre de post qui se plaignent que les interfaces et les implmentations ne sont pas spares dans des fichiers distincts en java... Notez quand mme:
> 
> 1) on n'a besoin de l'interface que pour des raisons de "documentation" (au sens large), c'est  dire pour comprendre comment utiliser telle ou telle objet... En java il y a la javadoc, trs rpandue et trs pratique, et bien plus claire qu'un fichier .h, sinon il y a les vues "outline" dans les diteur, qui permettent de filtrer 
> Mais par piti, arrtez de vous plaindre de l'absence des fichiers .h... pour moi c'est une abberration


j'ai dj dit plus haut pourquoi on ne peut se passer de fichiers .h (et quivalents) avec des langages compils en natif et  n'a rien  voir avec les seuls besoins de documentation pour l'humain qui lit le code c'est indispensable lors de la compilation 

et de fait ils sont totalement inutiles avec des langages qui gnrent du byte code qui contient toutes les informations de "Reflection" ncessaires

----------


## pseudocode

> Exactement:
> 
> 
> ```
> 
> ```
> 
> provoque l'erreur
> 
> ...


Ah, exact. Dans ma tte je pensais plus  un  "MaClass *c1 = new MaClass();". La (mauvaise) habitude de Java sans doute.  ::aie:: 





> Ce que tu appelle permissivit, j'aurais tendance  l'appeler libre arbitre.
> 
> Tu remarqueras que c'est encore une question de point de vue


Tout a fait. C'est 100% une histoire de point de vue, mais c'est un peu ce qui est demand dans les questions du 1er post.  ::P:

----------


## Oussapik

> Mais par piti, arrtez de vous plaindre de l'absence des fichiers .h... pour moi c'est une abberration


Je pense, il faudrait hiura confirme, qu'il ne cherchait pas  se plaindre de l'absence des fichiers .h (ou quivalent) en java. Il s'agit plutt de dbattre (visiblement, il y a des pour et des contre) de l'importance de leur prsence en C++. L'vocation de Java ne sert ici que de comparaison. Le but de ce topic n'est pas de se plaindre du Java

----------


## Guulh

> j'ai dj dit plus haut pourquoi on ne peut se passer de fichiers .h (et quivalents) avec des langages compils en natif et  n'a rien  voir avec les seuls besoins de documentation pour l'humain qui lit le code c'est indispensable lors de la compilation 
> 
> et de fait ils sont totalement inutiles avec des langages qui gnrent du byte code qui contient toutes les informations de "Reflection" ncessaires


J'ai pratiqu le C# bien plus que le C++, ma question pourra donc paratre nave, mais qu'y a-t-il dans un .h qui ne soit pas automatiquement extractible du .cpp ?
Je comprends bien la ncessit des headers, en l'absence dans les fichiers compils d'informations de rflexion. Mais pourquoi doit-on encore se carrer a  la main ?

Et quel est le lien entre le fait que le code soit natif ou pas, et le fait que les binaires soient autosuffisants ? (l encore, la question n'est pas rhtorique)

----------


## befalimpertinent

> je trouve SGI et MSDN trs brouillon (enfin j'avoue que j'ai jamais t foutu de comprendre comment MSDN tait range).
> Quant  roguewave, je ne connaissais pas et je dcouvre en ce moment mme.


Chacun ses gouts mais personnellement, je prfre cplusplus/reference


Pour ceux qui est des .h, bien que a ne m'ait jamais vraiment drang on peut reprocher au C++ l'inconvnient de devoir rajouter (quand on fait a proprement) un .i.h pour les inlines par exemples ou un .t.h pour les templates sans avoir l'lgance des class partiels du C#

----------


## hiura

> Je pense, il faudrait hiura confirme, qu'il ne cherchait pas  se plaindre de l'absence des fichiers .h (ou quivalent) en java. Il s'agit plutt de dbattre (visiblement, il y a des pour et des contre) de l'importance de leur prsence en C++. L'vocation de Java ne sert ici que de comparaison. Le but de ce topic n'est pas de se plaindre du Java


Techniquement je peux pas dire que c'est bien les headers en C++ et que c'est (aussi) bien de pas en avoir en JAVA. Donc dans un sens je critique bien JAVA.  ::aie:: 

Mais bien sr que l'ide n'est pas l. Ce n'est qu'un exemple pour comparer, comme l'exemple avec l'Objective-C.

----------


## ManusDei

> J'ai pratiqu le C# bien plus que le C++, ma question pourra donc paratre nave, mais qu'y a-t-il dans un .h qui ne soit pas automatiquement extractible du .cpp ?


Moi je mets des commentaires, destins  un utilisateur qui n'aura pas ncessairement accs au .cpp mais qui se sert des fonctions.

----------


## hiura

> Chacun ses gots mais personnellement, je prfre cplusplus/reference


Si je ne dis pas de btise (merci de me corriger si c'est le cas), SGI, MSDN, et compagnie, sont des implmentations tandis que cplusplus n'est qu'une doc (avec des erreurs). Si tu veux une doc fiable, tu as dinkumware certes un peu abrupte au dbut.

----------


## Guulh

> Moi je met des commentaires, destins  un utilisateur qui n'aura pas ncessairement accs au .cpp mais qui se sert des fonctions.


S'il existe un outil qui extrait un h  partir d'un cpp, il sera tout aussi capable d'extraire les commentaires.

----------


## Invit

Les principaux reproches que je fais au langage C++ sont principalement d'un point de vue syntaxique...

Les indispensables aprs une accolade fermante d'une dclaration de classe, union, numration, etc...

La notion d'itrateurs... a serait magnifique qu'un mot-cl C++ du genre foreach apparaisse, bien que des alternatives Boost/Qt soit dj prsente...

Les directives de pr-processeur... Pourquoi ne pas tout simplement utiliser des mot-cls pour les quelques oprations dont le pr-processeur se charge ?

Les pointeurs... Il serait intressant de mettre plus en avant les rfrences,  la manire du Java un peu...

L'impossibilit de sparer dclaration et implmentation de fonctions template, statique...

Laisser le choix entre les paradigmes orients objet et procdural pour des fonctions tel que le main.

En gros il faudrait passer  Java ou  D...  ::aie::

----------


## Florian Goo

> Les principaux reproches que je fait au langage C++ sont principalement d'un point de vue syntaxique...
> 
> Les ; indispensables aprs une accolade fermante d'une dclaration de classe, union, numration, etc...


C'est li au fait que l'on peut crire ceci :


```

```




> La notion d'itrateurs... a serait magnifique qu'un mot-cl C++ du genre foreach apparaisse, bien que des alternatives Boost/Qt soit dj prsente...


Ce sera dans le prochain standard  :;):  (C++0x) :


```

```

(fonctionne avec tous les conteneurs fournissant des itrateurs)




> Les pointeurs... Il serait intressant de mettre plus en avant les rfrences,  la manire du Java un peu...


Les rfrences en Java SONT des pointeurs. C'est juste qu'on ne peut pas agir sur eux aussi librement qu'en C++.
Les rfrences (les vraies) existent en C++.




> L'impossibilit de sparer dclaration et implmentation de fonctions template, statique...


C'est une ncessit de la compilation.




> Laisser le choix entre les paradigmes orient objet et procdural pour des fonctions tel que le main.


Histoire d'avoir un public static int main() comme en Java ? Quel intrt ?

----------


## pseudocode

> Histoire d'avoir un public static int main() comme en Java ? Quel intrt ?


J'avoue que je ne vois pas non plus. Ou alors c'est histoire de pouvoir en mettre un par classe sans que le linker ne rle ?  ::koi::

----------


## koala01

> J'ai pratiqu le C# bien plus que le C++, ma question pourra donc paratre nave, mais qu'y a-t-il dans un .h qui ne soit pas automatiquement extractible du .cpp ?


Les dclarations des fonctions et des classes.

Cela n'a l'air de rien, mais le compilateur ne connait que ce qu'il a dj rencontr.

Dans les langages  base de bytecode / machine virtuelle ou pour lesquels l'implmentation des fonctions de fait dans le mme fichier que la dclaration de celles-ci, il y a moins de problmes, dans le sens o il y a une "machinerie extrieure" (les import de java, par exemple) qui fera le lien entre les diffrents fichiers.

Cette "machinerie extrieure" est divise en deux parties en C et en C++:
Le prprocesseur, qui s'assurait (grce  la directive #include et toute sa clique) que le compilateur connaitra ce qu'il faut au moment o il le faut etl'diteur de liens qui s'assurera, une fois que tout aura t compil, que les appels de fonctions pointent bien vers... la fonction adquate (qui peut se trouver dans un fichier "objet" diffrent)

D'un autre ct, la sparation entre la dclaration et l'implmentation permet, quant  elle, de ne fournir que le "stricte minimum"  l'utilisateur d'une classe / structure / fonction :

Lorsque tu dcides d'utiliser une classe ou une fonction cre par quelqu'un d'autre, ce qui t'importe, c'est "l'interface" (dans le sens gnrique du terme et non dans le sens java  :;): ) quelle propose: elle te prsente tel ou tel service, correspondant  telle ou telle fonction.

A la limite, la manire dont la fonction fournit son rsultat, tu n'en as strictement rien  faire, et tu choisis de faire confiance  celui qui a programm la classe ou la fonction pour qu'elle rende correctement le service attendu.

Il n'y a donc, a priori, aucune raison pour que tu aies accs  ce genre d'information (qui, bien souvent, ne t'intresse de toutes manires pas, hormis  ::P: )  :;): 



> Je comprends bien la ncessit des headers, en l'absence dans les fichiers compils d'informations de rflexion. Mais pourquoi doit-on encore se carrer a  la main ?


Parce que personne n'a encore eu l'ide de faire en sorte qu'un environnement de dveloppement le fasse automatiquement, ventuellement aprs avoir pos une question sur l'accessibilit de la fonction  ::question:: 



> Et quel est le lien entre le fait que le code soit natif ou pas, et le fait que les binaires soient autosuffisants ? (l encore, la question n'est pas rhtorique)


Quand tu as un code binaire natif, tu n'as, en gros, qu'une "succession sans queue ni tte" de bytes, dans laquelle tu ne disposes d'aucune information permettant de faire le lien avec "trucs" crits en langage humain, et qui ne prend un sens que pour le processeur.

Il devient donc difficile, pour ne pas dire impossible, de retrouver des informations permettant d'aider... l'humain au dpart de ce code binaire.

Les langages bass sur du bytecode permettent de garder "suffisamment d'informations" pour les retransmettre  l'humain, mais ncessitent, en retour, un nouveau "passage  la moulinette" pour permettre au processeur de travailler.

Ce n'est pas tout  fait juste, et cela n'utilise sans doute pas les bons termes, mais cela permet de comprendre l'ide, non  ::question:: 



> Les principaux reproches que je fais au langage C++ sont principalement d'un point de vue syntaxique...
> 
> Les indispensables aprs une accolade fermante d'une dclaration de classe, union, numration, etc...


Ma premire raction a t d'tre d'accord, avant de me rappeler que l'on pouvait dcider de crer une instance nomme d'une classe / structure / union non nomme  ::aie:: 



> La notion d'itrateurs... a serait magnifique qu'un mot-cl C++ du genre foreach apparaisse, bien que des alternatives Boost/Qt soit dj prsente...


La fonction foreach apparait en C++1x.

La notion d'itrateur est prsente depuis longtemps  ::D: 



> Les directives de pr-processeur... Pourquoi ne pas tout simplement utiliser des mot-cls pour les quelques oprations dont le pr-processeur se charge ?


Quelle diffrence y aurait-il  avoir un mot cl import qui permettrait d'crire


```
import une_classe
```

plutt que 


```
#include <une_classe.h>
```

D'autant plus que cela poserait un problme assez bte dans le sens o la moindre classe, y compris une classe vide, devrait tre dfinie dans un fichier tout  fait spar.

Tu imagines, avoir un fichier nulltype, un autre voidtype et un troisime flagtype, alors que ces structures seraient toutes proches de


```

```

Sans compter les structures drives de FlagType  ::question:: 

Tu te retrouverais avec une quantit impressionnante de fichiers qui rendrait la gestion de ceux-ci encore plus complique qu'elle ne l'est  ::P: 



> Les pointeurs... Il serait intressant de mettre plus en avant les rfrences,  la manire du Java un peu...


a, c'est encore un problme d'apprentissage.

Il faut rellement insister sur le fait qu'il faut utiliser les rfrences partout o c'est possible et les pointeurs uniquement lorsque l'on n'a pas le choix  ::aie:: 

Il faut bien penser que les pointeurs permettent des choses que les rfrences ne permettent pas  :;): 



> L'impossibilit de sparer dclaration et implmentation de fonctions template, statique...


Ce sont des problmes dus au processus de compilation.

Pour ce qui est des fonctions template, par exemple, le compilateur doit disposer du type rel pour fournir le code binaire correspondant.

Comment faire pour qu'il arrive  fournir ce code binaire si... il ne dispose pas du code (source) quand il dispose du type rel  ::question:: 



> Laisser le choix entre les paradigmes orient objet et procdural pour des fonctions telles que le main.


Je sais que java permet, effectivement, de dfinir une fonction principale dans plusieurs classes.

Mais c'est la machine virtuelle qui permet de dcider d'appeler l'une plutt que l'autre.

Et les systmes d'exploitation ne prsentent, actuellement, pas ce genre d'opportunit  ::aie::

----------


## Invit

La surcharge de l'oprateur == a t longuement voque, sauf sur un aspect : que veut dire EGAL, a peut vouloir dire IDENTIQUE, PAREIL, MEME-VALEUR etc.
Une exemple : une ligne est une succession de points. Un point est caractris par son matricule et ses coordonnes. 
Si je compare 2 points de mme coordonnes, mais pas de mme matricule, ils sont superposs, mais ce ne sont pas les mmes points. Or pour qu'une ligne soit une zone il FAUT qu'elle se referme sur le mme point.
On peut aller un peu plus loin : deux points sont considrs identiques si leurs coordonnes diffrent de moins de 3 units de base.
En conclusion, pour une classe simple (ma classe Point3D) et qui en gros ne comporte que des constructeurs, j'avais 3 faons diffrentes de surcharger ==. Je n'ai donc pas surcharg l'oprateur.

Par contre, j'ai une classe Vecteur, et le test de paralllisme "||" me semble bien adapt, puisqu'il rpond  des critres prcis. A l'occasion d'un exemple, j'ai mis ce bout de code et on m'a dit que c'tait  viter, mais sans me dire pourquoi d'ailleurs  ::cry:: . 
Donc j'ai un peu de mal  comprendre. Mais  voir le nombre de ractions, je constate qu'au moins la moiti des membres a du mal  comprendre ce que dit l'autre moiti  ::lol::

----------


## hiura

> Ce sont des problmes dus au processus de compilation.
> 
> Pour ce qui est des fonctions template, par exemple, le compilateur doit disposer du type rel pour fournir le code binaire correspondant.
> 
> Comment faire pour qu'il arrive  fournir ce code binaire si... il ne dispose pas du code (source) quand il dispose du type rel


a n'en reste pas moins un point ngatif (rien que du fait que ce ne soit pas homogne avec la pratique de sparation dfinition/implmentation utilisable pour le reste). Non  ::question::  (Je pose rellement la question (sur le ngatif) car pour l'instant je n'ai pas pratiquer les templates assez pour avoir une relle exprience avec eux et donc je ne suis pas apte  dfinir l'impact que le regroupement obligatoire dfinition/implmentation a (temps de compilation/complexit de lecture par l'humain/).)

----------


## koala01

> a n'en reste pas moins un point ngatif (rien que du fait que ce ne soit pas homogne avec la pratique de sparation dfinition/implmentation utilisable pour le reste). Non  (Je pose rellement la question (sur le ngatif) car pour l'instant je n'ai pas pratiquer les templates assez pour avoir une relle exprience avec eux et donc je ne suis pas apte  dfinir l'impact que le regroupement obligatoire dfinition/implmentation a (temps de compilation/complexit de lecture par l'humain/).)


Cela peut, effectivement, tre considr comme un point ngatif du point de vue de l'homognit du dveloppement.

La ncessit qui est faite de rompre avec une habitude de sparation stricte des dclarations et des implmentation est assez "malheureuse" dirons nous.

Je ne vois, en l'tat actuel, malheureusement pas comment nous pourrions y remdier.

Et puis, l'approche base sur les template est une approche tout  fait particulire et fait malgr tout (pour celui qui fait plus qu'utiliser des classes template "toutes faite") appel  un savoir faire assez particulier  ::P: 

j'aurais donc tendance  dire que c'est effectivement un problme pour celui qui "dbarque" dans ce monde trange qu'est la programmation gnrique, mais que cela n' handicape pas outre mesure celui qui l'utilise rgulirement  ::P:

----------


## hiura

Et de ce que j'en ai vu les templates sont  elles seules un point bien positif du C++ donc ce petit dsagrment n'est qu'un dtail.

Je suis une girouette!  ::aie::

----------


## koala01

> Et de ce que j'en ai vu les templates sont  elles seules un point bien positif du C++ donc ce petit dsagrment n'est qu'un dtail.
> 
> Je suis une girouette!


Pas forcment, car je comprend ton point de vue  ::P: 

Vu "de l'extrieur", la rupture des pratiques de sparations est effectivement un aspect ngatif.

Par contre, si on largit son point de vue, on se rend compte de l'norme flexibilit que peuvent apporter les template, et l'on se dit que ce "lger dsagrment" est trs largement contrebalanc par le bnfice que l'on peut retirer de la programmation gnrique.

Aprs, libre  tout un chacun de dterminer ce qui lui importe le plus  ::D:

----------


## jblecanard

De plus, on peut quand mme sparer l'interface des templates et leur implmentation dans deux fichiers, en n'oubliant pas d'inclure le fichier d'implmentation  la fin du header. Comme a, on vite l'entorse intellectuelle.

----------


## Florian Goo

> La surcharge de l'oprateur == a t longuement voque, sauf sur un aspect : que veut dire EGAL, a peut vouloir dire IDENTIQUE, PAREIL, MEME-VALEUR etc.
> Une exemple : une ligne est une succession de points. Un point est caractris par son matricule et ses coordonnes. 
> Si je compare 2 points de mme coordonnes, mais pas de mme matricule, ils sont superposs, mais ce ne sont pas les mmes points. Or pour qu'une ligne soit une zone il FAUT qu'elle se referme sur le mme point.


C'est pour cela qu'on fait la distinction entre les classes  smantique de valeur et celles  smantique d'entit !
Il n'y a pas dambigut ds lors que la smantique d'une classe est bien dfinie.




> Par contre, j'ai une classe Vecteur, et le test de paralllisme "||" me semble bien adapt, puisqu'il rpond  des critres prcis. A l'occasion d'un exemple, j'ai mis ce bout de code et on m'a dit que c'tait  viter, mais sans me dire pourquoi d'ailleurs .


C'est simplement parce que tu dtournes la signification (ou smantique) de l'oprateur.  ||  signifie OU logique, pas paralllisme.

----------


## Invit

> Les principaux reproches que je fais au langage C++ sont principalement d'un point de vue syntaxique...
> 
> Les indispensables aprs une accolade fermante d'une dclaration de classe, union, numration, etc...
> 
> La notion d'itrateurs... a serait magnifique qu'un mot-cl C++ du genre foreach apparaisse, bien que des alternatives Boost/Qt soit dj prsente...
> 
> Les directives de pr-processeur... Pourquoi ne pas tout simplement utiliser des mot-cls pour les quelques oprations dont le pr-processeur se charge ?
> 
> Les pointeurs... Il serait intressant de mettre plus en avant les rfrences,  la manire du Java un peu...
> ...


pointeurs : Tu me fais de la peine ::cry:: 
Quand sun a sorti java, son marketing prsentait les rfrences comme plus "modernes" puisque elle ne permettent pas au dveloppeur (animal imprvisible et parfois bizarre) de crasher la machine !

Comme dit Koala, les ref sont des pointeurs, mais les pointeurs ne sont pas des ref !!
Le pointeur , c'est le truc qu'on utilise pas quand on dbute et dont on abuse quand on devient aguerri
Sa raison d'tre est qu'il correspond aux adresses que le processeur manipule, on retrouve sa valeur dans le binaire dsassembl d'un debugger binaire. 
Sa puissance est immense et les risques aussi ! 
exemple : la recherche dans une string (indexOF en C#, strchr() en C) retourne un pointeur sur la 1re occurrence ou NULL si non trouv. Ainsi pour chaque occurrence, un accs  l'intrieur de la chaine originale sera possible . En C# , on rcupre un offset qui ne permet d'accder  la sous-chaine qu'aprs l'avoir copie dans une autre string(subString()). En C , pas de copie, l'accs est implicite. En C++ , les CString ressemblent au C# et la mme manipulation exige une conversion.

Bref de tous les languages, C est le seul qui ne convertit rien, ne copie rien , et ne fait pas un new String pour stocker le rsultat.. (malloc() en fait) resultat : C = 0 CPU consomm pour le traitement des chaines.

Maintenant , si aucune occurrence n'est trouve, et que le pointeur null est retourn , toute tentative de lecture ou criture  cette adresse provoque une erreur irrcuprable (kill task sous XP) . On crit  l'adresse 0 ! 
En fait l'adresse 0 est convertie par le memory manager unit en adresse de segment de donnes , ce qui est moins "grave" que l'adresse physique 0, mais crashe tout quand mme !

Le prprocesseur me manque cruellement en C#.. comme il ne manipule que le texte du source, le compilateur ne voit que ce qu'il produit, c'est un immense avantage dans certains cas. et un dsastre parfois (MFC5 apr exemple)
Il faut savoir que le mode d'adressage le plus rapide des CPU est le mode direct :
la valeur est crite en clair dans le binaire. Le prprocesseur permet de le faire  et remplace donc la variable qui est plus lente  l'execution..

@+

----------


## Invit

> Les directives de pr-processeur... Pourquoi ne pas tout simplement utiliser des mot-cls pour les quelques oprations dont le pr-processeur se charge ?


C'est  double tranchant. D a voulu se passer de prprocesseur et fait exactement ca.

#ifdef => version
#if => static if
macros => strings mixinx + CTFE
#include => import

Il y a les avantages que l'on imagine en terme de parsing et de vitesse de compilation.

Mais il y a un inconvnient pervers  ne pas avoir de prprocesseur. Tout les chemins de code, mme non compils, doivent tre parss quand mme. Hors le principal avantage du prprocesseur est de permettre  des compilateurs diffrents / pas  jour / du futur de marcher quand mme...

Par exemple, crire du code compatible D version 1 et D version 2 est pnible  cause de a...

----------


## gl

> S'il existe un outil qui extrait un h  partir d'un cpp, il sera tout aussi capable d'extraire les commentaires.


Oui, extraire les commentaires n'est pas ce qu'il y a de plus compliqu.

Par contre savoir ce qui doit tre extrait dans le .h public, ce qui doit l'tre dans un .h priv, ce qui ne doit pas l'tre, etc; cela devient vite trs compliqu  moins de rajouter pas mal de mcanique pour indiquer quoi faire. Ce qui au final risque d'tre plus compliquer que d'crire soit mme les .h.

----------


## gl

> La seule exception que je connaisse au principe de garder une smantique identique est celle de boost::serialize qui utilise l'oprateur & dans une smantique qui n'est pas habituelle.


On pourrait aussi citer boost::spirit ainsi que certains DSL mais l on s'loigne de la smantique C++ pour se rapprocher de la smantique du domaine d'application, ce qui me semble plutt tre une bonne chose.

----------


## Invit

Merci pour vos remarques, mais je ne comprend pas toujours en quoi le pr-processeur est indispensable. 

Un autre reproche que je fais au C++ est ne pas prendre en compte la valeur de retour d'une fonction dans sa signature.

Concernant le ; aprs la dclaration d'une classe, union, etc... je ne savais pas qu'on pouvait crer et instanci une structure anonyme comme a, on en apprend tout les jours. Mais dans le cas ou on ne s'en sert pas... pourquoi ne pas le rendre optionnel ?

----------


## gorgonite

> Un autre reproche que je fais au C++ est ne pas prendre en compte la valeur de retour d'une fonction dans sa signature.



cites-moi un langage objet "mainstream" qui le fasse...

----------


## koala01

> Merci pour vos remarques, mais je ne comprend pas toujours en quoi le pr-processeur est indispensable.


Parce qu'un compilateur ne connait que ce qu'il a dj rencontr...

Quand tu crit, dans un fichier (qu'il soit *.h ou *.cpp) une directive comme


```
#include "fichier.h"
```

Le compilateur va copier rcursivement le contenu de fichier.h  la place de la directive.

(comprend par "rcursivement le fait que, s'il rencontre une directive include lui demandant d'inclure un autre fichier, il fera exactement pareil).

De plus, c'est un moyen extrmement puissant pour "tuner" l'application en fonction de certaines configurations, voire, pour permettre une compatibilit accrue.

Imaginons (car c'est un cas frquent) que l'on souhaite sur une bibliothque pour laquelle on souhaite fournir une version statique (compilateur dpendante) et une version dynamique / partage (dll).

Le code sera identique  un point prs: un __declpsec prcdera les fonctions que l'on veut exporter.

Tu ne va pas commencer  crire deux fois l'implmentation (une avec et l'autre sans le declspec) et trois fois le fichier d'en-tte (une sans __declspec pour la version statique, une avec __declspec(dllexport) pour la compilation de la dll et une avec __declspec(dllimport) pour l'utilisation de la dll).

Par contre, le prprocesseur est un outil gnial pour grer cela.

Il te suffit en effet d'crire quelque lignes, et de passer une option de compilation pour grer cela:


```

```

Lorsque tu compilera ta bibliothque sous la forme de:


```
g++  fichier.cpp -o fichier.o
```

tu compilera la version statique de ta bibiliothque.

Lorsque tu compilera ta bibliothque sous la forme de


```
g++ fichier.cpp -DUSE_MYDLL -o fichier.o
```

 tu compilera la version dynamque de ta bibliothque
Lorsque tu utilisera le fichier d'en-tte sous la forme de
g++ un_autre_fichier.cpp  -o un_autre_fichier.o
(on considre que un_autre_fichier.cpp inclu fichier.h  :;): ) tu prparera le terrain pour une utilisation de la version statique de la bibliothque

Et, enfin, lorsque tu utilisera le fichier d'en-tte sous la forme de


```
g++ un_autre_fichier.cpp -DUSE_MYDLL -o un_autre_fichier.o
```

(mme remarque que prcdemment  ::D: ) tu prparera le terrain pour une utilisation de la version dynamique de la bibliothque.

Tu pourrais trouver des applications similaires pour la gestion des compilateurs ne respectant pas trop la norme.

Ainsi, les anciennes versions de borland ne supportent pas le spcificateur d'exception (throw() ) alors qu'il est obligatoire pour d'autres.

Tu peux facilement contourner le problme sous une forme proche de


```

```


Tout cela tend  rendre le prprocesseur ncessaire.

Il y aurait peut tre d'autre moyens d'y parvenir, mais je ne vois vraiment pas lesquels  ::D: 



> Un autre reproche que je fais au C++ est ne pas prendre en compte la valeur de retour d'une fonction dans sa signature.


Aucun langage ne le fait, et aucun langage n'oblige d'ailleurs  rcuprer la valeur de retour d'une fonction  ::P: 



> Concernant le ; aprs la dclaration d'une classe, union, etc... je ne savais pas qu'on pouvait crer et instanci une structure anonyme comme a, on en apprend tout les jours. Mais dans le cas ou on ne s'en sert pas... pourquoi ne pas le rendre optionnel ?


Tu imagines un peu le bordel que cela foutrait dans le malheureux esprit du programmeur  ::question:: 



```

```

Non, sincrement, le plus facile est de ne faire qu'une rgle, qui ne souffre aucune exception, non  ::question::

----------


## Guulh

koala, Je te remercie d'apporter toutes ces prcisions  ::): 



> Les dclarations des fonctions et des classes.
> Cela n'a l'air de rien, mais le compilateur ne connait que ce qu'il a dj rencontr.


Est-ce une feature ou une limitation ? Du fait de la (relative) anciennet de C / C++, il ne m'est pas toujours facile de distinguer les choix de design volontaires des choix "faute de mieux".




> D'un autre ct, la sparation entre la dclaration et l'implmentation permet, quant  elle, de ne fournir que le "stricte minimum"  l'utilisateur d'une classe / structure / fonction


Je connais le concept d'encapsulation et de modularisation du code, et je sais que les diffrents langages le permettent de diffrentes faons  ::):  Mais strict, c'est vite dit, les membres privs et inline sont aussi prsents, non ? Y'a quand mme mieux qu'un .h, pour prsenter l'interface d'un module  un consommateur.  ::):  Sans parler de pimpl.




> Parce que personne n'a encore eu l'ide de faire en sorte qu'un environnement de dveloppement le fasse automatiquement, ventuellement aprs avoir pos une question sur l'accessibilit de la fonction


Ca serait un gain certain de productivit, non ? Et une preuve de plus que le header n'est qu'une contrainte du mode de compilation ?
'fin, je veux dire, les langages voluent pour nous faciliter la vie, thoriquement  ::):  (et les IDE suivent pour boucher les trous)



> Il devient donc difficile, pour ne pas dire impossible, de retrouver des informations permettant d'aider... l'humain au dpart de ce code binaire.
> Les langages bass sur du bytecode permettent de garder "suffisamment d'informations" pour les retransmettre  l'humain, mais ncessitent, en retour, un nouveau "passage  la moulinette" pour permettre au processeur de travailler.


Je ne vois toujours pas le lien entre le fait que ce soit du natif ou du byte code d'un ct, et le fait que les mta-donnes soient prsentes ou pas. On peut bien imaginer qu'un binaire C++ contienne aussi l'quivalent des .h ?

----------


## gorgonite

> Mais strict, c'est vite dit, les membres privs et inline sont aussi prsents, non ? Y'a quand mme mieux qu'un .h, pour prsenter l'interface d'un module  un consommateur.  Sans parler de pimpl.



et qui te dit que le .h(pp) prsent  l'utilisateur d'une bibliothque correspondra  son contenu rel ?

dans mon labo, on trafique ce genre de chose assez souvent, et pas toujours  fin d'ofuscation...

----------


## koala01

> koala, Je te remercie d'apporter toutes ces prcisions 
> Est-ce une feature ou une limitation ? Du fait de la (relative) anciennet de C / C++, il ne m'est pas toujours facile de distinguer les choix de design volontaires des choix "faute de mieux".


C'est, trs certainement historique, mais peut tre aussi une contrainte de compilation...

N'oublie pas que tout ce qui est utilis par le processeur ncessite une certaine taille en mmoire pour tre reprsent.

Une machine virtuelle peut s'occuper de mettre de l'ordre dans tout cela, mais, lorsqu'il n'y a pas cette couche intermdiaire, il faut que les choses soient exactement l o elles sont attendues  ::P: 



> Je connais le concept d'encapsulation et de modularisation du code, et je sais que les diffrents langages le permettent de diffrentes faons  Mais strict, c'est vite dit, les membres privs et inline sont aussi prsents, non ? Y'a quand mme mieux qu'un .h, pour prsenter l'interface d'un module  un consommateur.  Sans parler de pimpl.


Effectivement, j'aurais du dire "aussi peu que possible", car il est, actuellement du moins, difficile de faire en sorte de n'avoir qu'une dfinition de classe partielle  un endroit donn, et d'avoir le reste de cette dfinition ailleurs (quoi que c'est  peu prs le rle de pimpl  ::D: )



> Ca serait un gain certain de productivit, non ? Et une preuve de plus que le header n'est qu'une contrainte du mode de compilation ?
> 'fin, je veux dire, les langages voluent pour nous faciliter la vie, thoriquement  (et les IDE suivent pour boucher les trous)


C'est, effectivement, une volution logique...

Tu sais ce qu'il te reste  faire  ::D: 



> Je ne vois toujours pas le lien entre le fait que ce soit du natif ou du byte code d'un ct,


Reprenons:

Lorsque tu utilise un langage bas sur du bytecode et une machine virtuelle (comme java), le compilateur va faire "la moiti du travail" seulement:

Il va, par exemple, transformer toutes les instructions qu'il peut en instructions processeur, mais va laisser une partie d'informations qui devront tre... transformes par la machine virtuelle.

Ce seront, entre autres, des parties qui permettront, justement,  la machine virtuelle de retrouver fichiers de bytecode correspondant aux autres classes, et donc de les mettre en relation.

D'une certaine manire, le bytecode est... un code binaire mal fini  :;):  ::P: 

Par contre, le code binaire natif est destin ... ne plus tre modifi d'une quelconque manire une fois qu'il a t cr (hormis modification dans le code source suivie d'une recompilation).

C'est la raison pour laquelle il se doit d'tre "aussi pur que possible".

Les diffrents types ne sont plus considrs que... comme l'espace mmoire qui est ncessaire pour les reprsenter, et les membres des structures ou classes ne sont plus reconnus que par... le dcalage depuis le dbut du type en question qui est ncessaire pour y accder.




> et le fait que les mta-donnes soient prsentes ou pas. On peut bien imaginer qu'un binaire C++ contienne aussi l'quivalent des .h ?


Ce serait catastrophique  ::aie:: 

Tu imagine le nombre de donnes inutiles qu'il faudrait placer dans un fichier qui est, en toute logique, destin uniquement au processeur  ::question:: 

Entre le nom des types eux-mmes, le nom et le type des membres et la signature des diffrentes fonctions, tous les excutables verraient sans doute leur taille doubler ou tripler sans le moindre effort  ::P: 

Le pire, c'est que ce serait purement et simplement inutile, car, comme je l'ai indiqu, le code binaire excutable n'est pas susceptible d'tre modifi autrement qu'au travers de la modification des sources et la recompilation, et parce qu'il n'y a rien de prvu pour accder  ces informations

----------


## bioinfornatics

> cites-moi un langage objet "mainstream" qui le fasse...


je suis pas sr d'avoir bien compris, mais si c'est d'adapt le type de la variable selon le type de retour de la fonction, le D le fait grace au mot cl auto (le vala aussi)


```
auto maVar = funcReturnChar();
```

----------


## stardeath

si je ne dis pas de btise c'est que par exemple :


```
int getValue(int, long);
```

aura la mme signature que :


```
float getValue(int, long);
```

----------


## koala01

> je suis pas sr d'avoir bien compris, mais si c'est d'adapt le type de la variable selon le type de retour de la fonction, le D le fait grace au mot cl auto (le vala aussi)
> 
> 
> ```
> auto maVar = funcReturnChar();
> ```


Ca, la prochaine norme le prvoit aussi  :;): 

Je crois que ce que reproche abdelite (n'hsite pas  me dtromper  ::D: ), c'est que le compilateur ne considre pas les fonctions


```

```

et


```
std::string foo(A a, B b, C c)
```

comme deux fonctions diffrentes du fait d'un type de retour diffrent.

En effet, seul le nom, le nombre et le type des arguments est pris en compte pour la signature d'une fonction, et le compilateur n'acceptera jamais d'avoir deux fonctions ayant le mme nom mais des types de retours diffrents  :;): 

Et cela a quelque chose de logique, dans le sens o le nom d'une fonction doit indiquer le service que l'on peut en attendre, et que le fait de changer le type de retour tend  laisser croire que le service rendu change galement  :;): 

[EDIT] Ceci dit, il y a parfois des choses sympa  faire  ::D: :


```

```

La seule chose, c'est que l'valuation d'un type de retour n'est pas automatique, comme ca peut tre le cas pour les paramtres  ::P:  ::aie:: 
[/EDIT]

----------


## bioinfornatics

> Ca, la prochaine norme le prvoit aussi


La prochaine norme a fini par tres moins innovante que ce qu'elle voulait au dbut.
De plus le temps que tout le monde se mettent a utiliser la norme il va se passer 10 ans, dans 5 ans 70% . Surtout que le C++ a un cycle long de standardisation.
La nouvelle norme prvoyait la lune au final on a des fragment lunaires ... dommage

j'tais galement impatient des retomb de cette normes et au final ....
j'aime le c++ mais dans l'avenir je me tournerais vers le D.
Mais je reconnais qu'en D il y a moins de bibliothques c'est normales, la jeunesse.
D'ailleurs je vais me lancer dans la cration de quelques bibliothques.

----------


## guillaume07

moi il n'y a rien qui me drange dans ce langage, je le trouve quasi parfait

----------


## atttchoum

> Un autre reproche que je fais au C++ est ne pas prendre en compte la valeur de retour d'une fonction dans sa signature.


imaginons que tu ais :



```

```

C'est pas un problme li au C++

----------


## pseudocode

> imaginons que tu ais :
> 
> 
> 
> ```
> 
> ```
> 
> C'est pas un problme li au C++


Hum... comme l'a dit koala01, c'est surtout un problme conceptuel plus que technique. Le polymorphisme sert a offrir une interface de service unique pour des types de paramtres diffrents. Il est donc sous entendu que le service rendu (= le rsultat, et donc le type de retour) soit toujours le mme.

Ce n'est pas un problme technique dans le sens o le problme se pose mme pour les paramtres.


```

```

Sans dfinition explicite de ce que veut faire le dveloppeur, il est ncessaire de dfinir dans le langage des rgles pour grer ce genre de cas (covariance/contravariance).

----------


## befalimpertinent

> Et pour vous, quel est le dfaut le plus gnant du C++ ?


Son processus trs lent de normalisation. J'ai l'impression qu'il se passe un peu la mme chose qu'avec l'OpenGL 3.0.  ::?:  a fait maintenant un paquets d'annes qu'on entend parler de C++0X puis C++1X sans en voir le bout (2010 ou 2011 c'est promis !) donc les attentes sont grandes vu que pendant ce laps de temps les language concurrent (C#) progresse rapidement et par bonds importants (Linq, WPF, ...).
En plus de mme qu'avec l'OpenGL (je sais que les deux approches ne sont pas tout a fait comparables) il y a un risque d'obtenir un consensus mou au final : concepts exclu de la prochaine norme par exemple.
J'utilise pourtant avec le compilo de VS2010 les nouveauts du draft (auto, rvalue, lambda expression principalement  ::ccool:: ) mais il me manque encore le GC facultatif notamment.

Sign un C++iste impatient qui voit autour de lui les nouveaux projets dmarrer en C# et qui craint de devenir le dernier des mohicans.  ::cry::

----------


## Invit

Dans ce cas comme pour les templates, il faudrait indiquer au compilateur quelle version prendre quand l'ambigut est prsente... 



```

```

----------


## Invit

Bonjour




> Je rajouterais :
> *- la portabilit toute relative.*
> - le ddain de la STL par les librairies graphiques ( qui chacune redfinissent les types de bases, chanes, listes, tableaux...)
> - la complexit  intgrer des modules dvelopps par des moyens diffrents
> 
> JB


Le mot est faible. 

La STL est tellement mal implmente que mme Electronic Arts a d la rcrire pour ses besoins. 

Je ne vois pas l'intrt d'avoir plusieurs syntaxes pour les pointeurs (celle hrite du C et celle propre au C++ avec "&") ni l'intrt des pointeurs puisque laisser cet accs bas niveau  la mmoire est surtout dangereux d'une part et empche (ou complique notablement) l'implmentation de certaines optimisations mmoire au niveau du compilateur. C'est une des raisons qui explique que C++ n'est pas indtrnable en terme de vitesse d'excution et de gestion mmoire.

Le prprocesseur est pour ma part aussi un point ngatif. On ne sait plus trop ce qu'on a  la fin, je prfrerais pouvoir dtecter l'OS  l'excution (et mettre du code dpendant d'une plateforme dans un branchement conditionnel) au lieu de jouer avec les #ifdef. Cependant, avec le compilateur GNU, il me semble qu'il existe une option pour voir le code source aprs traitement des directives du prprocesseur ce qui peut s'avrer rudement utile.

Globalement, je trouve qu'au fil du temps, la syntaxe de C++ permet de faire tellement de choses de tellement de faons que a rend certains codes trs difficiles  lire.

Je sais que c'est trs subjectif mais je trouve que Visual Studio n'arrive toujours pas  la cheville d'Eclipse bien que j'arrive  dboguer le code pas  pas de manire assez similaire.

Enfin,  choisir, je prfrerais avoir un vrai _garbage collector_ et une gestion unifie des objets  la place d'un type de pointeur distinct (_smart pointer_).

----------


## zul

> La STL est tellement mal implmente que mme Electronic Arts a d la rcrire pour ses besoins.


a ne veut rien dire comme phrase.  la rigueur, l'implmentation de la STL par tel compilateur est tellement mauvaise que EA a du la recrire pour ses besoins, ou bien, EA n'a rien compris au fonctionnement de la STL et  a prfr recrire sa version. (La STL est plutt bien pens en gnral, on peut  la rigueur avoir des reproches sur les streams mais bon c'est pas vraiment dans la STL).




> Je ne vois pas l'intrt d'avoir plusieurs syntaxes pour les pointeurs (celle hrite du C et celle propre au C++ avec "&") ni l'intrt des pointeurs puisque laisser cet accs bas niveau  la mmoire est surtout dangereux d'une part et empche (ou complique notablement) l'implmentation de certaines optimisations mmoire au niveau du compilateur. C'est une des raisons qui explique que C++ n'est pas indtrnable en terme de vitesse d'excution et de gestion mmoire.


Les deux n'ont pas la mme smantique, et ont des usages diffrents. Je sais, c'est difficile  comprendre. L'usage de pointeur bas-niveau peut tre utile, surtout quand on utilise le C++ comme un langage systeme. Sinon, j'aimerai bien savoir quelle langage dtrone un bon compilateur C++ en terme de perfo (et un mec qui code raisonnablement videmment).




> Enfin,  choisir, je prfrerais avoir un vrai garbage collector et une gestion unifie des objets  la place d'un type de pointeur distinct (smart pointer).


Tu fais trop de Java  ::):  Si tu veux un garbage collector, personne ne t'empeche d'en utiliser un (a fait longtemps qu'il en existe ....). Quand la "gestion unifi des objets", je ne sais pas ce que tu entends, mais le RAII est bien plus homogne que GC + finally + ... pour grer les diffrents types de ressources.

Le problme majeur de C++, c'est manifestement que ce n'est pas du Java ou du C#  ::D: , voire pire qu'on ne raisonne pas pareil en C++ que dans les deux autres sus-cits.

EDIT : LINQ on peut faire des choses proches en C++, sans changer de normes / compilateur (voir Linq++ par exemple http://hjiang.net/archives/229, ou Oven : http://p-stade.sourceforge.net/oven/doc/html/index.html. Pour WPF, je ne sais pas ce que tu regrette (je ne fais pas bcp de dev graphique), mais Qt intgre aussi un langage dclaratif pour dcrire des interfaces, voir faire des choses hautement dynamiques (et a a le bon got d'tre portable)). C'est  mon avis hors du scope de C++ d'avoir une spec graphique, (et vu ce que a a donn en Java, non merci)).

----------


## gorgonite

> je suis pas sr d'avoir bien compris, mais si c'est d'adapt le type de la variable selon le type de retour de la fonction, le D le fait grace au mot cl auto (le vala aussi)
> 
> 
> ```
> auto maVar = funcReturnChar();
> ```


euh, a n'a rien  voir avec le fait d'avoir des signatures prenant en compte le type de sortie... ce serait plus proche de la forme la plus basique qu'on puisse imaginer de l'infrence de type  ::?: 

par ailleurs, tant qu'il n'y a aucun mcanisme d'unification, ou un non respect de l'objet "classique", j'ai beaucoup de mal  voir comment le compilo pourrait se dbrouiller seul (quid de l'objet et de l'infrence de type sous F#, ou alors cf modle infrence objet de OCaml)

----------


## Invit

> Son processus trs lent de normalisation. J'ai l'impression qu'il se passe un peu la mme chose qu'avec l'OpenGL 3.0.  a fait maintenant un paquets d'annes qu'on entend parler de C++0X puis C++1X sans en voir le bout (2010 ou 2011 c'est promis !) donc les attentes sont grandes vu que pendant ce laps de temps les language concurrent (C#) progresse rapidement et par bonds importants (Linq, WPF, ...).
> En plus de mme qu'avec l'OpenGL (je sais que les deux approches ne sont pas tout a fait comparables) il y a un risque d'obtenir un consensus mou au final : concepts exclu de la prochaine norme par exemple.
> J'utilise pourtant avec le compilo de VS2010 les nouveauts du draft (auto, rvalue, lambda expression principalement ) mais il me manque encore le GC facultatif notamment.
> 
> Sign un C++iste impatient qui voit autour de lui les nouveaux projets dmarrer en C# et qui craint de devenir le dernier des mohicans.


J'adhre : ta solitude est grande    mohican  ::): 

Je ralise qu'en dfendant C++ et ses lourdeurs, j'irais  l'encontre du grand topic et risquerais de m'attirer les foudres du roi des mes dont la lumire blafarde des dalles lcd cache l'immense qute d'ides neuves..

C'est vrai que pour faire bouger cette montagne de c++, il faut plus ou moins obtenir le consensus entre tous les grands diteurs de la plante. La plupart des propositions doivent recueillir beaucoup de contestation et le standard fait du sur-place.

Cela dit,  mon niveau, peu de projets 100% C++ mais beaucoup de projets multi languages auxquels le C/C++ apportent leur performance imbattable alors que les parties back office sont programmes sur visual studio, java ou n'importe quel language moins contraignant. 

En retournant le problme, on reproche frquemment la petitesse de la librairie. La conclusion que j'en tire est que pour laisser un maximum de libert aux diteurs trs jaloux de leurs mthodes, on les incite  crer leur propre extensions alors que le "core" du langage reste minimaliste.

On peut aussi reprocher  certains langage de rendre obligatoire l'utilisation d'un produit de l'diteur qui va affecter toute l'activit de l'diteur :Windows, Android, Iphone sont aussi d'normes librairies dont l'usage n'est pas anodin

On pert d'un cot l'avantage d'une librairie intgre au core qui rend l'IDE trs confortable, mais on grade le choix du system d'exploitation, du processeur ou contrleur, etc...   Dans les faits, c'est vrai que le C est le dernier qui reste quand on fait une carte  processeur (solutions hard+soft) 

ma conclusion :
Pour un developpement PC ,  moins de disposer de budgets normes (que je n'ai jamais vu en France) dvelopper un front office 100% C/C++ me semble quasi impossible. Donc je confie les parties ultra sensibles au C et le reste  C# (dans mon cas) mais a peut aussi tre du C++ manag ce qui revient au mme et ne transforme pas compltement le pur mohican en "rat des villes" si tu vois ce que je veux dire.

Vu que je pense comme a, le C garde ma prfrence et C++ devient un peu bancal car quitte  faire de l'objet, j'aime autant profiter des dernires avances en terme de productivit..   

Si je devais un jour (incertain) grer un projet pharaonique en full C++ (genre mozilla) , je changerais drastiquement mon fusil d'paule et je serais sans doute, comme toi, plus svre avec la lenteur de l'volution du language. J'ai d laisser un peu de la philosophie en chemin pour des raisons assez business je l'avoue

----------


## ManusDei

> Sinon, j'aimerai bien savoir quelle langage dtrone un bon compilateur C++ en terme de perfo (et un mec qui code raisonnablement videmment).


FORTRAN il me semble.

----------


## bioinfornatics

Le D trs trs proche niveaux perf

----------


## bacelar

> Sinon, j'aimerai bien savoir quelle langage dtrone un bon compilateur C++ en terme de perfo (et un mec qui code raisonnablement videmment).


Ce nest pas un langage mais un dveloppeur qui utilise les bons outils et qui n'a pas deux mains gauches.  ::aie::  ::ccool::

----------


## JPLAROCHE

bin    moi rien a reprocher

peut tre parce je code comme sur l'AS400

par contre j'ai mis plus de 8 mois  choisir  et tester
l ' EDI  la bibliothque le type de base de donne  (simple  & complexe) et la Librairie de rfrence pour le designer pour faire les crans et dition,
la librairie pour faire du dcimal    (l peut tre une chose qui devrait tre implment par dfaut)

puis btir les routines de fond pour accs BD AS400

je pense que le temps est  prendre  avant de commencer quoi que ce soi 

le C ou C++  peut tre trs propre rapide et simple 

hier on apprenait la mthode AXIAL chez IBM ( 1980 OBJET le tout OBJET pas ++)  bien sur pas de ce cot de l'atlantique mais ont y avait accs
et j'ai t form  cela c'tait rvolutionnaire ...... 1976

ps( je signal que ADA est de 1980) l' OBJET par excellence


le concurrent AXIAL --> MERISE  


aujourd'hui on devrait faire  AXIAL et apprendre la thorie des ensembles (raisonner avec) ainsi garder un oeil sur MERISE (cohrence de la base de donnes)


-----------------------------------------------------------------------
le tout objet avec hritage  c'est bien mais c'est comme pas du tout 

alors C++  OUI de tout faon  il est notre assembleur d'aujourd'hui et notre LG3 si les LIB. sont prsentes 


@plus de vous lire intressant les articles.

----------


## Guulh

> On peut bien imaginer qu'un binaire C++ contienne aussi l'quivalent des .h ?





> Ce serait catastrophique 
> 
> Tu imagine le nombre de donnes inutiles qu'il faudrait placer dans un fichier qui est, en toute logique, destin uniquement au processeur


Donc c'est bien un choix, li  des problmatiques de performance, pas une consquence du fait que le code soit natif. Le surcot en poids des jar et des assemblies (et plus gnralement, je suppose, pour les langages avec des API d'introspection) est-il rdhibitoire ?
Dans le binaire ou  ct d'ailleurs, si la taille du fichier est un problme. Comme un header me direz-vous  ::aie:: , oui, mais gnr tout seul.

Je comprends bien tout ce que tu me dis, mais je trouve cher pay de devoir saisir du code en double (voire en triple ou plus, si comme le dit gorgonite on crit aussi un .h "d'export"  destination des utilisateurs du binaire) pour de seules problmatiques de compilation.

Il y a un tel cart entre C/C++ et Java/C# (je ne parle que de ce que je connais mme vaguement, d'o l'association honnie entre C et C++ dans mon raisonnement  ::aie:: ) qu'il est difficile de savoir quels aspects dcoulent d'un choix de design particulier (ce qu'implique l'usage de bytecode, par exemple), et quels autres sont des choix volontaires. 

C'est ce que j'ai constat en travaillant en C++ : quand quelque chose parat inutilement compliqu pour la tche  accomplir, difficile de faire le tri entre les aspects ncessaires au code bas niveau, les idiosyncracies du langage, sa quasi-compatibilit avec C, les problmatiques de portabilit, de performance, et les dlires mystiques de Stroustrup  ::):

----------


## Oussapik

> Je ne vois pas l'intrt d'avoir plusieurs syntaxes pour les pointeurs (celle hrite du C et celle propre au C++ avec "&")


Ce ne sont pas plusieurs syntaxes pour des pointeurs, c'est que ce ne sont pas du tout les mmes choses. Leur utilit est bien diffrente. Ou alors, je n'ai pas compris ta remarque.




> ni l'intrt des pointeurs puisque laisser cet accs bas niveau  la mmoire est surtout dangereux d'une part et empche (ou complique notablement) l'implmentation de certaines optimisations mmoire au niveau du compilateur.


Laisser de l'accs  la mmoire te semble faire perdre la possibilit d'implmenter des optimisations mmoire ? Je pense compltement le contraire. Certains langages ont fait le choix de la mmoire gre automatiquement. Je pense alors que c'est dans ce cas que l'on perd les possibilit d'optimisation. Les algos d'optimisations des dits-langages sont comme tout, il peuvent comporter des failles. Et c'est l tout l'intrt de grer a  la main, on peut adapter la gestion de la mmoire au contexte.

----------


## Invit

> bin    moi rien a reprocher
> 
> peut tre parce je code comme sur l'AS400
> 
> par contre j'ai mis plus de 8 mois  choisir  et tester
> l ' EDI  la bibliothque le type de base de donne  (simple  & complexe) et la Librairie de rfrence pour le designer pour faire les crans et dition,
> la librairie pour faire du dcimal    (l peut tre une chose qui devrait tre implment par dfaut)
> 
> puis btir les routines de fond pour accs BD AS400
> ...


Salut JP , bienvenue ici, homme avis et qui a juste l'age qui m'arrange le plus  ::):  (moi 46)

Je ne comprends pas tout mais pour ce je reconnais, le fait d'avoir un vcu et d'avoir connu l'avant C++ rend philosophe quant  ses limites

Je crois qu' l'origine de ce topic (passionnant au demeurant), est la complainte d'un gars qui pond du code C++ toute la journe ce qui explique le caractre un peu lger de la question pose.

Celui qui a le choix de l'architecture replace C++ l o il est le plus utile et utilise autre chose pour les tches rcurrentes o la productivit est importante.

Mais on ne peut pas ignorer que les grands diteurs mondiaux font du full C++ et que dans ce cas, ses limites prennent une toute autre dimension
La faon dont la question est pose pse sur les rponses

Je crois deviner ce que tu dis concernant merise , je suis bien d'accord mme si la jeunesse a us ses neurones sur le couple java/design patterns. La priorit  merise nous semble vidente puisque elle concerne tous les cas de figure alors que patterns prche le religion de l'objet au point de perdre le contact avec l'objectif initial : un programme rapide robuste capable de monter en charge.
Je peux me tromper mais, il me semble que merise n'est pas trs compatible avec l'hritage multiple qui est un des points les plus controverss de C++ .

D'ailleurs personne ici ne nous a fait le coup du "j'utilise l'hritage multiple tous les jours et c'est gnial !" 

 Bon, la question pose tait donc un peu plus lgre que certains l'ont laiss entendre.

----------


## pseudocode

> Ce ne sont pas plusieurs syntaxes pour des pointeurs, c'est que ce ne sont pas du tout les mmes choses. Leur utilit est bien diffrente. Ou alors, je n'ai pas compris ta remarque.


Vous avez tous les deux raisons et je pense que c'est le problme.  ::aie:: 

Visiblement il y a une incomprhension entre les personnes qui ont des critiques sur l'utilisation du langage C++, et les personnes qui dfendent les solutions techniques proposes par le langage.

Personnellement, je ne remet pas en cause les choix "techniques" qui ont t fait, ni les contraintes qu'ils engendrent. Je m'interroge plutt sur les raisons "pratiques" qui ont amen a faire ces choix : sont-elles toujours d'actualit, ont-elles volu, ou disparu.

----------


## Invit

On parle beaucoup de langage, mais peu de dveloppement.
Il y a eu une petite tentative hier, qui consistait  mettre les choses sur la table (je parle de copies d'cran par exemple) le suggestion n'a pas t releve.

Par ailleurs, un objet est un ensemble d'lments divers groups sous une seule identit, une classe. Si cette affirmation est juste, je voudrais bien qu'on m'explique comment on peut comparer deux objets. Soit ils sont identiques, et donc il y en a un de trop, soit ils des caractres communs, ou semblables ou pareils, alors on pourra crire des fonctions comme 


```

```

Mais que pourrait-il y avoir dans un code de surcharge de l'oprateur == ?
Remarque : ceci n'est pas un exemple comme dans ma prcdente question.
Il s'agit tout de mme de la mme question, mais pas la peine de rpondre sur l'exemple.
Quel est l'oprateur que l'on peut surcharger pour tester un paralllisme de deux vecteurs?

----------


## Invit

Concernant les perfs, il n'y a pas 36 chemins. Il est impossible de dpasser la performance d'une routine en assembleur bien faite et optimise. 
C a t appel "l'assembleur procdural"  une poque. Des diteurs comme Borland avaient ajout des librairies assembleur et communiquaient beaucoup l dessus. 
D'autres approches que le C sont convaincantes mais elles passent toutes par une utilisation encore plus directe de l'assembleur (je pense  PureBasic) 

Maintenant il est parfaitement ridicule de gagner un cycle machine par seconde sur un pc de bureau et c'est l que commence le malentendu.
Car il est trs important de gagner un cycle CPU sur le droulement d'une boucle infinie dans un programme qu'on instancie 200 fois sur un serveur de data center qui en contient 2000 !

Cette priorit  l'optimisation utile (profiling) est une affaire de design et requiert une connaissance du mtier, du march et mme une culture gnrale.  Tous les languages se disent rapides (sauf le Shell script  ::):  )  mais quand il s'agit de limiter la consommation lectrique du processeur , la selection devient plus dure (cf : Apple ipad) 

L'embarqu a remis cette question de perf au got du jour alors que plus personne n'en parlait depuis la sortie des dual core

Ceux qui comme moi , ont beaucoup travaill sur les perfs (straight coding, calculs en matrice, latence telecom, ...)   reconnaissent assez vite leurs pairs !  Mme si l'industrie a dpens bien plus  optimiser javascript que les programmes de M tout-le-monde. C est la seule approche raisonnable en la matire. Ne me parlez pas d'objet alors que mme le procdural est optimisable. Chaque rcursion est couteuse et le fait que le monde entier ait opt pour le C/C++ est quand mme plus parlant que les prtentions de tel ou tel diteur.

Ceci dit il est aussi ridicule d'optimiser le droulement d'un language qui se chiffre en secondes si on fait des accs disques sans arrt ou qu'une tche concurrent le fait.   

9 fois sur 10 l'optimisation ultime consiste  grouper les tches autour d'une zone cpu+cache(register) / RAM / disque / rseau

----------


## bacelar

> Par ailleurs, un objet est un ensemble d'lments divers groups sous une seule identit, une classe


Bin non.
On peut avoir les mmes donnes mais avec des mhodes compltement diffrentes qui implmente les mmes interfaces.

Le cas pathologique de la smantique "==" est la comparaison de chaine de caractre.
"==" donne vrai si c'est le mme pointeur ou que le contenu est le mme (sans compter les problmes d'encodage, de culture, de case sensitivit etc..).
C# a rgl le problme par un choix qui est au niveau de l'implmenteur de la classe.

Vous n'imaginez pas la complexit de l'implmentation de la class string de C# pour avoir une smantique de comparaison qui correspond au contenu tout en ayant de trs bonne performance.
Je dis a, car j'ai l'impression que les C++ puristes ont tendance  prendre les autres pour des nains de jardins.  ::aie::

----------


## guillaume07

> Quand je vois "void*" dans un code en C++, je commence  m'inquiter srieusement  la base.


Pourquoi ? quel est le problme avec les void* ?

----------


## bacelar

Pour les performances, je pense que l on a un choc de culture.
Les C++ puristes pensent qu'ils peuvent toujours faire mieux qu'une implmentation standard (du GC par exemple).
Moi, je suis bien plus circonspect. Je teste le GC et s'il ne me convient pas je le customise. En C++, mais aussi en C#, car vous ne devez pas prendre les fonctionnalits .NET pour une boite ferm. Vous pouvez plus ou moins facilement tout customiser.
Cela permet de dgager bien plus de temps pour l'algorithmie, les optimisations adaptatives ou encore prendre en compte les besoins clients fluctuants.

----------


## bacelar

> Pourquoi ? quel est le problme avec les void* ?


C'est juste tyleless, c'est juste encore plus dangereux et immaintenable que du typage dynamique.

----------


## bacelar

> 9 fois sur 10 l'optimisation ultime consiste  grouper les tches autour d'une zone cpu+cache(register) / RAM / disque / rseau


Avec des GPGPU, SMP, multi-core etc... cela devient un peu plus complexe, donc n'ayez pas peur d'utiliser l'expriences des implmenteurs de Framework et autres VM.

----------


## Invit

> Pour les performances, je pense que l on a un choc de culture.
> Les C++ puristes pensent qu'ils peuvent toujours faire mieux qu'une implmentation standard (du GC par exemple).
> Moi, je suis bien plus circonspect. Je teste le GC et s'il ne me convient pas je le customise. En C++, mais aussi en C#, car vous ne devez pas prendre les fonctionnalits .NET pour une boite ferm. Vous pouvez plus ou moins facilement tout customiser.
> Cela permet de dgager bien plus de temps pour l'algorithmie, les optimisations adaptatives ou encore prendre en compte les besoins clients fluctuants.


J'ai crit mon msg en mme temps que le vtre. Comme j'y parle de cas extrmes en embraqu alors que je fais du c# toute la journe, je veux juste prciser :
Certes la GC n'est pas en soi une optimisation de perf mais plutt une aide  la programmation (merci basic !) Cela dit, vu le temps que a fait gagner au developpeur, il est trs utile de la grer ou d'en tenir compte. Comme le collector de C# utilise Marshal pour parcourir tous les symboles en squence et que je n'ai jamais trouv de moyen de grouper les zones de mmoire en C#, il reste surtout  faire les Dispose(); avec astuce pour EMPECHER le collector de se lancer trop souvent..

Noter que j'adore ce langage, mme si je peste sans cesse sur le peu de contrle qu'on a sur l'agencement du segment de donnes et de la pile (qui est norme sous .net)

----------


## Invit

malloc() revoit un void*, et pourtant cette fonction a fait ses preuves et est encore trs utilise  ::?: . 
D'ailleurs, il est assez probable que new appelle malloc(), mais seuls les thoriciens du C++ pourraient rpondre.

----------


## Invit

> malloc() revoit un void*, et pourtant cette fonction a fait ses preuves et est encore trs utilise . 
> D'ailleurs, il est assez probable que new appelle malloc(), mais seuls les thoriciens du C++ pourraient rpondre.


J'ai peur que les grands thoriciens aient plus de got pour les beaux croquis avec de belles boites et de nombreuses flches  ::): 

Je confirme votre hypothse. New est la version objet de malloc(), calloc()

Par contre la gestion du C++ en ce qui concerne le delete() est aussi peu scurise que free() en C : crash si le pointeur rsultant de l'instance parente (argument) n'a pas fait fait l'objet d'un new. dispose() en C# est scuris et renvoie une erreur bien propre si on essaye de "librer" une constante par exemple. dispose() est en outre optionnel (merci la GC). En C++ sans GC delete() est compltement obligatoire (memory leak et crash alatoire sinon)

----------


## _skip

Je dirai quand mme que les points les plus dlicats ne sont pas  mon sens la surcharge d'oprateur ou les pointeurs.

La surcharge d'oprateurs n'est nuisible que si c'est une fonctionnalit mal utilise, quant aux pointeurs, il existe des solutions du ct des smart pointers. Le toolkit Qt par exemple, utilise des objets copy-on-write trs confortables qu'on peut tranquillement balader entre les fonctions, conserver en rfrence dans une classe, le tout sans risque de destruction prmature.

Le problme des dclarations sur deux fichiers h/cpp vient  mon sens de la duplication possible de la documentation, et les dclarations inline salissent un peu l'avantage de sparation cit par certains. En refactoring, la ncessit de modifier systmatiquement  plusieurs endroits peut s'avrer pnible.

J'ai par ailleurs toujours trouv dommage que les dveloppeurs C++ soient aussi rservs  l'gard des exceptions, prfrant crer une tonne de valeurs de retour spcialises. Balader un code d'erreur et un texte d'erreur sur plusieurs fonctions de profondeur (A appelle B appelle C appelle D appelle E) sachant que A a l'accs  l'interface utilisateur et permet d'afficher l'erreur tient du cauchemar. De nombreux if/else sont ncessaires aux tests de ces valeurs de retour et le code  crire peut vite tripler de taille.
Mais c'est l une question philosophique et un avis personnel surtout.

Actuellement le C++ est, je trouve dsavantag par rapport aux technos manages qui proposent toutes un grand panel d'outils pour les applications client-serveur, webservice, SOAP et tout cela. Le travail pour exploiter un webservice XML un peu sophistiqu en C++ peut tre vite un peu fastidieux, mme chose pour ce qui est service web.
Et les clients lgers, les applications webs ainsi que les RIA sont des domaines dont la demande a augment passablement, et malheureusement C++ a peu de cartes en main dans ces secteurs.
C'est l encore non pas une question de *capacit* du langage, mais d'cosystme et de simplicit de mise en oeuvre avec les technos et frameworks disponibles.

----------


## bacelar

new utilise malloc (et c'est mme pas obligatoire), mais renvoie une chose typ est c'est trs trs loin d'tre un hasard.
De plus, bon nombre d'implmentations de la lib C ajoutent bien des choses comme une vrification des tailles, utilisation de canaries etc. 
L'illusion du contrle du C++.  ::aie::

----------


## Invit

> Je dirai quand mme que les points les plus dlicats ne sont pas  mon sens la surcharge d'oprateur ou les pointeurs.
> ...


Merci Skip, point de vue trs intrressant. Je me demandais si un spcialiste QT allait s'interresser  nous..  ::):

----------


## bacelar

> C'est l encore non pas une question de *capacit* du langage, mais d'cosystme et de simplicit de mise en oeuvre avec les technos et frameworks disponibles.


Tout  fait d'accord, mais je m'hasard  une explication  la faiblesse de l'cosystme : Le nombre d'intervenant dans la norme et leurs motivations caches.

----------


## Invit

> new utilise malloc (et c'est mme pas obligatoire), mais renvoie une chose typ est c'est trs trs loin d'tre un hasard.
> De plus, bon nombre d'implmentations de la lib C ajoutent bien des choses comme une vrification des tailles, utilisation de canaries etc. 
> L'illusion du contrle du C++.


Malloc est une convention des OS qui s'occupent de la rservation mmoire. malloc() est la version C qui fait cet appel systeme avec plus ou moins de vrifications. Les OS tant tous en C/C++, les deux forment une seule entit.

J'aime bien le pointeur void * sur un morceau de ram moi ... 

Parfois j'y range des types simples ou structs, parfois des files, des buffers...   En embarqu parfois, je fais ma propre gestion ram en "empilant" les objets comme dans un flux de comm. Hormis le fait qu'il soit trs chatouilleux et que le free() soit difficile  forcer en cas d'erreur par exemple, je n'ai rien  lui reprocher.

En fait le typage d'un ptr est surtout utile pour les sizeof() (preprocesseur) ou l'arithmtique sur pointeurs, procd  combien performant et ne me pose pas de problme thique. Mais peut tre qu'un thoricien va me crier dessus...  

Je me rappelle avoir expliqu a  un conseil d'admin d'une socit du cac40 , ils taient tous rests comme deux ronds de flan.   Par la suite ils avaient tranch en ma faveur en disant qu'ils voulaient un logiciel "aux normes" de ma maquette. Ils ne s'taient pas risqus sur des termes techniques, ils voulaient juste "la mme chose"

En fait , je suppose que tous ceux qui n'aiment pas les pointeurs doivent trouver insupportable tout ce qu'on peut faire avec et qui est impossible avec des references...   

J'entends dire du mal des pointeurs depuis que java est sorti et depuis cette date , je les utilise de plus en plus , avec bonheur, efficacit et performances 

Il y a de quoi les mettre en ptard. Moi je suis fond  me poser de questions sur les gourous qui disent ce qui est bien et mal. Un programme qui marche depuis 15 ans sans un bug ,   c'est mal ?

----------


## zul

new appelle bien malloc qui appelle quelquechose de systme dpendant (sous Linux / BSD, a doit tre brk / sbrk()). void* peut avoir son utilit, quand on fait du systme / bas-niveau. C++ est aussi un langage de haut-niveau, avec un systme de typage fort. Ce typage fort permet :
   1/ de dtecter un certain nombre d'erreur
   2/ faire des optimisations

Dans ce cadre, utiliser void* (ou boost::any) on perd toutes ces informations, et donc toutes les garanties qui vont avec. Dans certains cas, c'est donc bien / voir ncessaire. Dans la grande majorit des cas, c'est une hrsie qui fait perdre un bon nombre d'avantages d'avoir un langage compil  typage fort.

----------


## bacelar

Comment outiller, vrifier ou tester automatiquement votre bout de code ?



> Un programme qui marche depuis 15 ans sans un bug


Un programme sans bug, cela n'existe pas.
Il y a toujours des cas d'utilisation qui le fera pter en vol, par exemple, le programme de Voyageur 2 sous le rayonnement solaire au bout de 33 ans.
Avec un outillage correct il est possible de faire un patchage automatique de ce genre de problme.

----------


## Florian Goo

> Je confirme votre hypothse. New est la version objet de malloc(), calloc()


Non, on peut faire des  new int  et des  new int[n] , rien  voir avec les objets.
J'ai plutt envie de dire que  new  est la version type-safe de  malloc() .




> Par contre la gestion du C++ en ce qui concerne le delete() est aussi peu scurise que free() en C : crash si le pointeur rsultant de l'instance parente (argument) n'a pas fait fait l'objet d'un new. dispose() en C# est scuris et renvoie une erreur bien propre si on essaye de "librer" une constante par exemple. dispose() est en outre optionnel (merci la GC). *En C++ sans GC delete() est compltement obligatoire (memory leak et crash alatoire sinon)*


C'est cela et les smart pointers servent juste  faire joli.
D'autant plus qu'un GC ne peut pas empcher toutes les fuites mmoire. Se reposer aveuglment sur le GC est une imprudence trop rpandue.

----------


## Invit

> new appelle bien malloc qui appelle quelquechose de systme dpendant (sous Linux / BSD, a doit tre brk / sbrk()). void* peut avoir son utilit, quand on fait du systme / bas-niveau. C++ est aussi un langage de haut-niveau, avec un systme de typage fort. Ce typage fort permet :
>    1/ de dtecter un certain nombre d'erreur
>    2/ faire des optimisations
> 
> Dans ce cadre, utiliser void* (ou boost::any) on perd toutes ces informations, et donc toutes les garanties qui vont avec. Dans certains cas, c'est donc bien / voir ncessaire. Dans la grande majorit des cas, c'est une hrsie qui fait perdre un bon nombre d'avantages d'avoir un langage compil  typage fort.


je comprend a. 
Mais l'embarqu, c'est la loi de la jungle. 
D'autre part, on fait toujours un malloc avec son cast. Cela rpond  cette question, on peut refaire le cast quand on veut.... je ne vois vraiment pas ou est le problme.

Enfin, j'apprcie dans C et moindre mesure C++ la possibilit de trouver du boulot dans l'embarqu de qualit spatiale ou militaire !!!!!  Ce n'est pas avec des gnralits qu'on obtient un projet top niveau, c'est avec des rsultats. 
Le C le permet, c'est fonctionnel, test avec protocoles. C'est document.

Ca marche.   Certains me l'ont accord  reculons mais ils ont d reconnaitre que je diminuais le cot du hardware , controleur moins rapide, batterie de capacit infrieure. 
L'argument de conformit n'a pas suffi ,  sinon j'aurais perdu la mission !  Il faut quand mme dire qu'en situation de march, le client a son mot  dire.

Je dois vous avouer que si emporter une comptition comme celle l consiste  chercher les failles d'ingnieur et violer igniominieusement les dogmes , c'est un exercice que je trouve extraordinairement gratifiant. Qu'un tel projet intresse Boeing et la Nasa relativise sur la mthode. Mme si ces deux socits ont juste demand de l'information.

----------


## jblecanard

> Un programme sans bug, cela n'existe pas.


H bien si, il y en un l.

----------


## Florian Goo

> Un programme sans bug, cela n'existe pas.


Bien sr que si, enfin.
Tu n'as jamais vu les pubs pour Google Chrome dans le mtro ?  ::D:

----------


## bacelar

Cela me rappel un bug dans une librairie qui tait en prod depuis plus de 15 dans des centaines d'excutables utiliss par des centaines de traders tous les jours.
Le hic, c'est qu'avec l'inflation et le montant astronomique des deals, et bien la taille d'un buffer en dur  foutu la merde pendant des mois, voir des annes pour certaines applications.
Mais elle ne pouvait pas tre bogu, cette librairie multi-plateforme utilise pendant plus de 15 ans par des centaines de dveloppeur. C'est I-M-P-O-S-S-I-B-L-E.  ::aie::  ::aie::  ::aie:: 
Mais sinon, le premier vol dAriane 5 ce nest pas un bug, on a juste pas lu les spcifications dtailles des composants logiciels. ::aie::  ::aie::  ::aie:: 
Jattends toujours le programme sans bug.  ::ccool::

----------


## Invit

> Non, on peut faire des  new int  et des  new int[n] , rien  voir avec les objets.
> J'ai plutt envie de dire que  new  est la version type-safe de  malloc() .
> C'est cela et les smart pointers servent juste  faire joli.
> D'autant plus qu'un GC ne peut pas empcher toutes les fuites mmoire. Se reposer aveuglment sur le GC est une imprudence trop rpandue.


je rends grce  votre tonnant sens du dtail. Il se peut que ce que vous dites ait du sens dans votre contexte. Mais dans le mien , a n'en a aucun. De quel genre de projet vous occupez-vous ?

Pourriez vous mieux prciser ?

----------


## Invit

> Cela me rappel un bug dans une librairie qui tait en prod depuis plus de 15 dans des centaines d'excutables utiliss par des centaines de traders tous les jours.
> Le hic, c'est qu'avec l'inflation et le montant astronomique des deals, et bien la taille d'un buffer en dur  foutu la merde pendant des mois, voir des annes pour certaines applications.
> Mais elle ne pouvait pas tre bogu, cette librairie multi-plateforme utilise pendant plus de 15 ans par des centaines de dveloppeur. C'est I-M-P-O-S-S-I-B-L-E. 
> Mais sinon, le premier vol dAriane 5 ce nest pas un bug, on a juste pas lu les spcifications dtailles des composants logiciels.
> Jattends toujours le programme sans bug.


Labondance du recours au smiley et la typographie sont elles destines a suggrer le mcanisme de zygomatiques ? srotonine, mimtisme ? empathie ? 

Les blagues de potaches sur les bugs abondent mais celle ci est elle vraiment ::?:  destine  faire rire ??

Le problme d'Ariane provenait d'un dfaut de testing, les parties incrimines taient fonctionnelles sur d'autres plateformes. Le protocole a t fortement amend depuis. Ce bug n'tait pas une bonne nouvelle pour l'ingnierie europenne et franaise en particulier. Pas plus que les accidents de navette ou qu'un crash d'avion.

----------


## Luc Hermitte

La thorie ? new appelle qui il veut.

La pratique ? Par dfaut il appelle rgulirement malloc. Mais il peut aussi prfrer telle ou telle autre fonction propritaire que le fournisseur a juge plus adapte au cas par dfaut.

La pratique bis ? On (nous, quoi) peut faire en sorte que new appelle ce que l'on veut. Par exemple, on peut le faire aller piocher dans un pool plutt que dans le truc par dfaut (malloc ou autre). Dans le mme genre, on peut plugger facilement un truc qui s'occupe de surveiller les double-librations.

----------


## pseudocode

> J'aime bien le pointeur void * sur un morceau de ram moi ... 
> 
> Parfois j'y range des types simples ou structs, parfois des files, des buffers...   En embarqu parfois, je fais ma propre gestion ram en "empilant" les objets comme dans un flux de comm. Hormis le fait qu'il soit trs chatouilleux et que le free() soit difficile  forcer en cas d'erreur par exemple, je n'ai rien  lui reprocher.
> 
> En fait le typage d'un ptr est surtout utile pour les sizeof() (preprocesseur) ou l'arithmtique sur pointeurs, procd  combien performant et ne me pose pas de problme thique. Mais peut tre qu'un thoricien va me crier dessus...  
> 
> (...)
> 
> En fait , je suppose que tous ceux qui n'aiment pas les pointeurs doivent trouver insupportable tout ce qu'on peut faire avec et qui est impossible avec des references...   
> ...


Ce que tu dcris c'est surtout la fonction "accesseur sur une zone mmoire" des pointeurs. Bref, quelque chose qu'on peut tout a fait proposer dans d'autres langages (C++, Java, ...) sans pour autant que cela soit le coeur du fonctionnement du langage comme dans le C.

En effet, rien n'empche de dfinir une classe qui manipule une zone mmoire linaire et fournit des accesseurs, de la srialisation, ...

Le C va plus loin dans le sens o tout ce qui est allou par le langage (les variables, les fonctions) est accessible sous forme de pointeur, un peu  la manire de la reflection. D'ailleurs j'utilise parfois la technique "C Objet" pour disposer du principe des instances dans des programmes en pur C.

----------


## Florian Goo

> je rends grce  votre tonnant sens du dtail. Il se peut que ce que vous dites ait du sens dans votre contexte. Mais dans le mien , a n'en a aucun.


Ce que je voulais dire, c'est que je trouve dommage de se dire qu'on utilise new juste parce qu' on fait de l'objet .
Je perois new comme une avance par rapport  malloc().  vrai dire, je ne perois pas l'intrt d'utiliser malloc() en C++.




> De quel genre de projet vous occupez-vous ?


En ce moment, je travaille sur une bibliothque d'analyse de code C++ (voir signature), crite elle-mme en C++. Difficile pour moi de cacher mon attrait pour ce langage  ::aie:: .




> Pourriez vous mieux prciser ?


Concernant les smart pointers (ou pointeurs intelligents), je crois qu'il existe des articles sur DVP qui te rpondront mieux que moi.
Concernant les fuites mmoires des GC, mme chose, je te conseille la lecture d'un article sur WeakReference (c'est du Java, mais il n'y a pas de raison que le GC de C# n'ait pas le mme problme).

----------


## Invit

> La thorie ? new appelle qui il veut.
> 
> La pratique ? Par dfaut il appelle rgulirement malloc. Mais il peut aussi prfrer telle ou telle autre fonction propritaire que le fournisseur a juge plus adapte au cas par dfaut.
> 
> La pratique bis ? On (nous, quoi) peut faire en sorte que new appelle ce que l'on veut. Par exemple, on peut le faire aller piocher dans un pool plutt que dans le truc par dfaut (malloc ou autre). Dans le mme genre, on peut plugger facilement un truc qui s'occupe de surveiller les double-librations.


Bien vu pour le pool et les liberations  rptitions, que d'crans bleus en moins..

----------


## koala01

> On parle beaucoup de langage, mais peu de dveloppement.
> Il y a eu une petite tentative hier, qui consistait  mettre les choses sur la table (je parle de copies d'cran par exemple) le suggestion n'a pas t releve.
> 
> Par ailleurs, un objet est un ensemble d'lments divers groups sous une seule identit, une classe. Si cette affirmation est juste, je voudrais bien qu'on m'explique comment on peut comparer deux objets. Soit ils sont identiques, et donc il y en a un de trop, soit ils des caractres communs, ou semblables ou pareils,


Soit, enfin, ils ont deux origines distinctes, et il est intressant de pouvoir dterminer qu'ils reprsentent une valeur commune.


 alors on pourra crire des fonctions comme 



> ```
> 
> ```
> 
> Mais que pourrait-il y avoir dans un code de surcharge de l'oprateur == ?
> Remarque : ceci n'est pas un exemple comme dans ma prcdente question.
> Il s'agit tout de mme de la mme question, mais pas la peine de rpondre sur l'exemple.


Et je vais pourtant y rpondre:

Si l'on peut estimer que deux objets quelconques sont considrs comme identique  partir du moment o ils ont:
la mme position d'origine (celle  partir de laquelle sont dtermines les autres cots)la mme surfacela mme longueurpeut tre d'autres prorits comparables, comme le nombre d'anglestu saura dterminer la logique  suivre pour ton oprateur ==

Si l'une de ces donnes est inutile, supprime la, tout simplement  ::D: 

Si tu considre que deux objets ne peuvent tre identiques que s'ils se rfrent  une mme instance, compare les adresses auxquelles ils se trouvent.

l'oprateur == est un oprateur de comparaison permettant de dterminer l'galit ventuelle entre deux oprandes.

A partir de l, libre  toi d'estimer, dans le cadre de ton projet, si une quivalence peut ou non tre considre comme galit, et, dans le cas d'objets disposant d'quivalences composables (une surface identique, mais pas forcment la mme longueur, ou vice versa), quelles quivalences permettront d'assurer l'galit lors de la comparaison.

----------


## Florian Goo

> Si tu considre que deux objets ne peuvent tre identiques que s'ils se rfrent  une mme instance, compare les adresses auxquelles ils se trouvent.


Dans ce cas-l (qui porte un nom : smantique d'entit), il est prconis de ne pas surcharger l'oprateur d'galit du tout.
Cf notre eeeexcellente FAQ http://cpp.developpez.com/faq/cpp/in...s#CLASS_entite  :;): .

----------


## koala01

> La bonne pratique dans ce cas-l (qui porte un nom : smantique d'entit), il est prconis de ne pas surcharger l'oprateur d'galit du tout.
> Cf notre eeeexcellente FAQ http://cpp.developpez.com/faq/cpp/in...s#CLASS_entite .


hh... aussi...

Et comme on travaillera souvent avec des pointeurs  ::aie:: ...

----------


## Invit

Oui, "pointeurs intelligent" ... moi, je prfre me rserver le ct intelligence dans l'application, et laisser au langage le soin de traduire en code excutable ce que j'cris en code lisible par moi et d'autres.
Quelque soit le nom du langage, je travaille avec ce que j'ai, et je m'en contente PAR DEFINITION.
Quand je lis "ce sera dans la prochaine version", je ne dis que j'ai bien raison de me contenter de ce que j'ai. Mon but n'est pas d'utiliser un langage mais de dvelopper. Je comprend ceux qui cherchent  crire ou amliorer un langage, il en faut, mais je ne pense pas que ce soient les mmes qui sont le mieux placs pour dire aux dveloppeurs comment ils doivent faire.  

Concernant la surcharge des oprateurs pour les classes. Il y a bien longtemps que j'ai compris que ce n'tait pas vraiment utilisable pour des objets, il ne peut y avoir qu'une seule surcharge du signe == et des quantits de choses susceptibles d'tre compares. Donc, sauf cas trs particuliers, je considre que c'est un gadget trs satisfaisant pour l'esprit, mais pas vraiment utilisable.

----------


## Florian Goo

> Oui, "pointeurs intelligent" ... moi, je prfre me rserver le ct intelligence dans l'application, et laisser au langage le soin de traduire en code excutable ce que j'cris en code lisible par moi et d'autres.


Je trouve moi aussi que le terme  intelligent  est plutt malheureux, d'autant plus que, contrairement  un GC, ils font en sorte de maintenir le dveloppeur concern par la gestion de la mmoire : leur usage est explicite et il existe plusieurs types de pointeurs intelligents dont chacun est adapt  une situation.




> Quand je lis "ce sera dans la prochaine version", je ne dis que j'ai bien raison de me contenter de ce que j'ai. Mon but n'est pas d'utiliser un langage mais de dvelopper. Je comprend ceux qui cherchent  crire ou amliorer un langage, il en faut, mais je ne pense pas que ce soient les mmes qui sont le mieux placs pour dire aux dveloppeurs comment ils doivent faire.


La notion de pointeur intelligent existe dans la STL depuis le dbut (std::auto_ptr, dont l'usage est certes dconseill, mais il existe). Il y a aussi (et surtout) ceux de Boost (en particulier shared_ptr).
Je ne sais pas si la dernire phrase de la citation m'est destine, mais je prends le C++ et les pointeurs intelligents pour ce qu'ils sont : des outils.




> Concernant la surcharge des oprateurs pour les classes. Il y a bien longtemps que j'ai compris que ce n'tait pas vraiment utilisable pour des objets, il ne peut y avoir qu'une seule surcharge du signe == et des quantits de choses susceptibles d'tre compares. Donc, sauf cas trs particuliers, je considre que c'est un gadget trs satisfaisant pour l'esprit, mais pas vraiment utilisable.


Nous sommes d'accord qu'il faut utiliser la surcharge d'oprateur avec sagesse. De l  dire que ce n'est pas utilisable
Je suis bien heureux de pouvoir crire  if(string1 == string2) . Je suis galement bien heureux que les conteneurs de la STL me garantissent un traitement optimal de mes objets en l'change de la surcharge des oprateurs de comparaison.

----------


## koala01

> Quand je lis "ce sera dans la prochaine version", je ne dis que j'ai bien raison de me contenter de ce que j'ai. Mon but n'est pas d'utiliser un langage mais de dvelopper. Je comprend ceux qui cherchent  crire ou amliorer un langage, il en faut, mais je ne pense pas que ce soient les mmes qui sont le mieux placs pour dire aux dveloppeurs comment ils doivent faire.


Pour autant que je sache, une bonne part de ceux qui participent  l'laboration de la nouvelle norme sont eux-mme des dveloppeurs reconnus qui ont retourn le langage dans tous les sens (l'un n'empche pas l'autre hein  ::D: )

Pour le reste des dveloppeurs, ceux du "commun des mortels" qui ne font qu'utiliser le langage, il est possible de considrer C++ comme le "moins mauvais langage" ( dfaut de le considrer comme le meilleur  ::D: ) et donc d'tre tout  fait conscient de certains problmes qui, justement, seront (peut-tre!!) rsolus dans la nouvelle mouture.

Ceux-l sont donc parfaitement en droit d'attendre cette nouvelle mouture avec impatience  ::D: 



> Concernant la surcharge des oprateurs pour les classes. Il y a bien longtemps que j'ai compris que ce n'tait pas vraiment utilisable pour des objets, il ne peut y avoir qu'une seule surcharge du signe == et des quantits de choses susceptibles d'tre compares. Donc, sauf cas trs particuliers, je considre que c'est un gadget trs satisfaisant pour l'esprit, mais pas vraiment utilisable.


C'est l que la notion de smantique de valeur ou d'entit intervient.

Certaines choses peuvent ou doivent tre comparables afin, par exemple, d'en permettre un tri:

Une chaine de caractres, par exemple, doit l'tre afin de permettre de placer Alphonse Baudais avant William Sheakespear (j'hsite sur l'orthographe des deux  ::aie:: )si le besoin s'en fait sentir.

Il en va de mme pour les vecteurs ou les matrices(au sens mathmatique du terme), par exemple.

Et, de manire gnrale, on peut souhaiter savoir si le contenu d'une collection d'objets correspond au contenu d'une autre, ou si un objet d'un type particulier peut tre considr comme identique  un autre ( charge pour le dveloppeur de dterminer ce qui rend les deux objets identiques) parce que les deux ont des origines diffrentes.

Ces comparaisons peuvent tre effectues avec des fonctions membres, mais on perd la possibilit d'un ventuelle rflexibilit que l'on pourrait tre en droit d'attendre de la part de certains types d'objets.

----------


## Floral

> Je trouve moi aussi que le terme  intelligent  est plutt malheureux, d'autant plus que, contrairement  un GC, ils font en sorte de *maintenir le dveloppeur concern par la gestion de la mmoire* : leur usage est explicite et il existe plusieurs types de pointeurs intelligents dont chacun est adapt  une situation.


Il me semble que c'est une question de point de vue encore ici: Soit on veut un programme o tout est sous contrle, mme la gestion mmoire, soit on dlgue a  une machine virtuelle ou  des paramtre que l'on aura laiss  l'intrieur de notre code source en fonction du langage utilis. En d'autre terme soit on se fait confiance -  soi-mme ou  nos dveloppeurs -, soit on fait confiance en les algorithmes - qui peuvent tout  fait convenir! - sur lesquels on a ou pas la forcment main.
Aprs il existe des bonnes pratiques dans certains langages qui n'ont aucun sens dans d'autre comme le RAII en C++, inapplicable en Java. Ce n'est qu'une question (mal place,  mon sens) d'affinit avec une plateforme ou un langage.

----------


## _skip

Pour la dfense de la surcharge d'oprateur, je me permet de citer ce cas en java :



```

```

Un code quivalent utilisant la surcharge d'oprateur (possible en c++) serait quelque chose comme :



```

```

Sans rire, c'est nettement plus lisible?

----------


## Klaim

En fait, a dpends : moi personellement en C++ j'aurais mis un constructeur explicit  un type BigDecimal , de manire  avoir plutot : 



```
BigDecimal tax = price * BigDecimal(19.6) / BigDecimal(119.6) ;
```


C'est plus lisible que Java sans tre aussi peu explicit (concernant les types impliqus) que ton exemple de C++.

Cela dit, une meilleure solution existera (et oui dans C++0x/1x, donc pas tout de suite, mais au moins elle est prvue) : les suffix custom  (par exemple ici BD pour BigDecimal) : 




> BigDecimal tax = price * 19.6BD / 119.6BD ;


Ca rsoudra ce genre de probleme de syntaxe lourde a cause des casts implicites.

----------


## pseudocode

> Pour la dfense de la surcharge d'oprateur, je me permet de citer ce cas en java :
> 
> 
> 
> ```
> 
> ```
> 
> Un code quivalent utilisant la surcharge d'oprateur (possible en c++) serait quelque chose comme :
> ...


Oui, c'est clair que c'est nettement plus lisible... Ces classes sont vraiment une plaie  utiliser en Java.  ::cry:: 

D'un autre cot, la smantique de ces oprateurs est assez vidente dans le contexte de l'arithmtique. C'est nettement mois vident si tu remplaces "BigDecimal" par "Triangle" ou "Dog".  ::aie::

----------


## Invit

> BigDecimal tax = price * 19.6BD / 119.6BD ;


Ca, a me rappelle le BasicA  ::mrgreen:: 
Mais si j'avais  faire une classe type BigDecimal, o le membre le plus important est le prix, je ferais quelque-chose comme a:


```

```

Et ... pas de surcharge d'oprateur, puisque P1 = new BigDecimal(...) et P2 = new BegDecimal(...) ne sont plus comparables.

----------


## Davidbrcz

> D'un autre cot, la smantique de ces oprateurs est assez vidente dans  le contexte de l'arithmtique. C'est nettement mois vident si tu  remplaces "BigDecimal" par "Triangle" ou "Dog"


D'ou les notions de classe a semantique de valeur et de celles a semantique d'entite ... On revient a la meme chose : Le C++ donne un outil, c'est pas la faute du langage si des idiots font nimporte quoi avec ....

Pierre Dolez >> Dune classe BigDecimal, a la vue de son nom, j'attends qu'elle represente d'une maniere speciale un nombre. Or la, il y a un dephasage entre le nom de ta classe et son role.

----------


## _skip

> D'un autre cot, la smantique de ces oprateurs est assez vidente dans le contexte de l'arithmtique. C'est nettement mois vident si tu remplaces "BigDecimal" par "Triangle" ou "Dog".


Tu as raison, mais personnellement je ne suis pas trop d'accord avec le principe qu'il faut bannir des fonctionnalits sous prtexte qu'on peut faire des choses bizarres avec. Je prfre un langage riche dont j'utilise 50%  un langage pauvre dont j'aurai besoin de 110%  ::mouarf:: . 

Je dirai que la redfinition d'oprateur devrait le plus souvent se borner aux cas o la smantique est justement comme tu le dis: vidente, ou tout au moins cohrente. 

Cependant, j'ai aussi vu dans un mappeur objet-relationnel en C# une approche intressante pour construire des filtres qui utilisait une syntaxe de ce genre :



```

```

La signature de la mthode tait 



```
void addCondition(IPredicate);
```

Ceci tait rendu possible par le fait que la classe des objets Price, Status, Customer avait ses oprateurs  <, >, ==, != redfinis de telle faon  retourner un objet implmentant l'interface IPredicate.

C'tait trs commode  utiliser et trs lisible, mme si a cassait la smantique relle des oprateurs, cependant les objets Fields ne servaient qu' cela et l'utilisateur du code ne crait pas d'instance.

----------


## jblecanard

C'est aussi super pratique dans boost::program_options. Certes, cela peut perturber le novice, mais a nous fait conomiser tellement de code en gnral...

----------


## bacelar

Les C++istes qui critiquent Java mais qui ne connaissent pas l'autoboxing.
http://lroux.developpez.com/article/..._2#Lautoboxing
Et a fait plus de 10 ans que je n'ai pas fait une ligne de Java.

Pour la syntaxe des prdicats en C#, c'est encore plus lisible avec LINQ.
Mais il ne faut pas trop essayer de se mettre  la place du compilateur, sinon c'est l'entorse de cerveau assure. (comme les templates  ::aie:: )

Avant de critiquer les autres langages, commencez  les connatre pour voir ce qui y est intressant.

----------


## pseudocode

> D'ou les notions de classe a semantique de valeur et de celles a semantique d'entite ... On revient a la meme chose : Le C++ donne un outil, c'est pas la faute du langage si des idiots font nimporte quoi avec ....


Dans ce cas particulier, c'est plus la notion de lisibilit du code qui me plait.

La notion de smantique valeur/entit ca me semble plus tre une tentative de rationaliser une situation ambige dans le langage : "est-ce qu'on parle du contenu (valeur) ou du contenant (entit)". Situation ambige qui (a mon sens) existe  cause de la cohabitation pointeur/rfrence dans le C++

----------


## Florian Goo

> Les C++istes qui critiquent Java mais qui ne connaissent pas l'autoboxing.
> http://lroux.developpez.com/article/..._2#Lautoboxing
> Et a fait plus de 10 ans que je n'ai pas fait une ligne de Java.
> C++iste est-il synonyme d'autiste ? Ou de jsuite de trs mauvaise foi ?


C'est diffrent.
Cela ne fonctionne qu'avec les types primitifs. En C++, on peut surcharger les oprations de cast quel que soit le type.

----------


## _skip

Quelqu'un peut m'expliquer o il est question d'autoboxing dans les derniers posts?

----------


## Florian Goo

> Situation ambige qui (a mon sens) existe  cause de la cohabitation pointeur/rfrence dans le C++


Pourquoi a ?

Il me semble que c'est un aspect de conception et non de langage. En C++, on se demandera  ma classe doit-elle surcharger == ?  et en Java  ma classe doit-elle redfinir equals() ? .

----------


## Florian Goo

> Quelqu'un peut m'expliquer o il est question d'autoboxing dans les derniers posts?


L'exemple avec BigDecimal, je pense.
Mais il y a effectivement confusion, vu que BigDecimal n'est ni un type built-in du C++, ni un type de la lib standard.

----------


## _skip

J'ai pas le temps d'essayer mais normalement la mthode multiply de BigDecimal en java a cette signature :


```

```

Si c'tait 


```

```

Je pourrai crire 


```

```

Mais pour le coup, vu que le type n'est pas Integer et que rien  ma connaissance ne boxe en bigDecimal, a devrait pas compiler. Dans le doute, je laisse le soin  celui qui affirme que je critique sans savoir d'essayer.

----------


## pseudocode

> Pourquoi a ?
> 
> Il me semble que c'est un aspect de conception et non de langage. En C++, on se demandera  ma classe doit-elle surcharger == ?  et en Java  ma classe doit-elle redfinir equals() ? .


Oui, je vois ce que tu veux dire. Mais comme "==" peut aussi tre utilis sur les pointeurs, ca devient plus compliqu de garantir sa smantique.



```

```




```

```


(aux erreurs de syntaxe prs  ::aie:: )

----------


## Florian Goo

Oh ben quand mme, habituellement le programmeur est un peu au courant du type des variables qu'il manipule. Tu chipotes !

Et aucune erreur de syntaxe comme quoi, tu vois que c'est facile, le C++  :;): .

----------


## bacelar

> Je pourrai crire 
> 
> Code :
> 
> 
> ```
> monBigDecimal.multiply( 10 );
> ```


Limitation de la Class BigDecimal, pas du langage qui ne force pas l'utilisation des objets  tout bout de champs.
Moi, j'ai toujours tendance  utiliser des float dans des constantes.  ::aie::

----------


## pseudocode

> Oh ben quand mme, habituellement le programmeur est un peu au courant du type des variables qu'il manipule. Tu chipotes !


Bah, au bout de une ou deux pages de code, c'est pas toujours gagn de savoir si on a pass les paramtres par rfrence (C++ style) ou par adresse (C style).  Surtout avec des dveloppeurs venant d'horizon diverses ayant chacun leur style de codage.  ::roll:: 

Mais c'est vrai que l c'est surtout un problme organisationnel, et un minimum de discipline dans le respect des rgles. Et puis c'est le genre de truc qu'un analyseur de code est capable de remonter.

----------


## gorgonite

> Bah, au bout de une ou deux pages de code, c'est pas toujours gagn de savoir si on a pass les paramtres par rfrence (C++ style) ou par adresse (C style).  Surtout avec des dveloppeurs venant d'horizon diverses ayant chacun leur style de codage.


tu oublies les rfrences sur les adresses  ::aie:: 




> Et puis c'est le genre de truc qu'un analyseur de code est capable de remonter.


des analyseurs efficaces sur C++... a n'intresse pas les personnes ayant le niveau de le faire, et il faut un niveau assez consquent avant de voir un rsultat pertinent (pire qu'un compilateur  ::mouarf::  )

----------


## Florian Goo

> des analyseurs efficaces sur C++... a n'intresse pas les personnes ayant le niveau de le faire, et il faut un niveau assez consquent avant de voir un rsultat pertinent (pire qu'un compilateur  )


*sifflotte*

----------


## gorgonite

> *sifflotte*


tu as une liste de proprits analyses, qui ne soient pas juste la traduction du code en AST, avec vrification de base ?


tu peux venir prsenter ton outil ici : http://www.developpez.net/forums/group.php?groupid=98 ?

----------


## bacelar

C'est bien le problme du C++.
Le manque d'outillage pour la validation, le mocking, les tests unitaires etc...

----------


## gorgonite

> C'est bien le problme du C++.
> Le manque d'outillage pour la validation, le mocking, les tests unitaires etc...



tests unitaires ? a existe
outils de validation... je demanderais juste ce que tu places derrire ce mot, car dans un cadre hors recherche, il existe plein d'outils pour des problmatiques concrtes dans un cadre trs prcis
(parce qu'au niveau calcul de WCET, va pas croire qu'il existe un outil de validation pour Java qui marche mieux  ::aie:: )

----------


## Invit

> C'est bien le problme du C++.
> Le manque d'outillage pour la validation, le mocking, les tests unitaires etc...


 Vous savez, moi, je m'en sors trs bien avec mon compilateur. 
Par ailleurs, je ne comprend pas pourquoi ce serait un problme du C++. Ce problme existe-t-il au moment de la rdaction du code? ou au moment de l'excution du binaire? Dans le second cas le langage n'a rien  voir. Dans le premier c'est un problme de compilateur et pas de langage ( mon avis).

----------


## bioinfornatics

en D on a de nouveau mot cl comme version, debug, testunit
ces mot forme un bloc ainsi on peut insrer un test unitaire


```

```

----------


## bioinfornatics

Les imperfections du C++ sont galement exprim ici: http://www.prowiki.org/wiki4d/wiki.cgi?PerfectD

----------


## hiura

> Les imperfections du C++ sont galement exprim ici: http://www.prowiki.org/wiki4d/wiki.cgi?PerfectD


Je me suis arrt  l'item 10 par manque de temps. Deux choses sur lesquelles je ne suis pas d'accord avec l'auteur.

Item 9 : techniquement char est un byte. Il n'est pas destin  tre affich en tant que chiffre mais peut tout  fait tre utilis de la sorte.

Item 10 : C and C++ need fixed-sized integer types. Au premier abord on peut croire que ce n'est pas bien. a impose certaines mesures dans les applications rseau notamment, certes. Mais a a du sens : au moment o la norme du langage est crite les machines ont certaines spcificits comme la mmoire qui vont voluer plus vite que la norme. Avoir une taille non fixe (mais prcise par des relations de grandeur entre les types eux-mmes!) est donc bien rflchis : ainsi la taille des types peuvent voluer  la mme vitesse que les machines.

Notons au passage la non-objectivit du papier (comme nos discussions  ::aie::  ). Il est vraiment tourn pour montrer les avantages du D.

----------


## guillaume07

honnetement je n'arrive pas  trouver de gros dfault, la reflexibilit c'est tout ce qui me manque

----------


## Invit

Je ne sais pas si c'est un dfaut ou une qualit, mais je le met  titre de comparaison.
Code quelconque


```

```

Code C++ faisant la mme chose


```

```

Je ne ferai pas de commentaire.

----------


## Luc Hermitte

> Les imperfections du C++ sont galement exprim ici: http://www.prowiki.org/wiki4d/wiki.cgi?PerfectD


Item 4: As Java, D has a synchronized keyword. 
Celui-l m'a bien fait rire. Comme si cela suffisait pour thrader correctement. Quid des futures, des taches et leurs queues de messages, des barrires, des compteurs atomiques, des TSS, ... Enfin bon. COmme plusieurs autres items, le prochain standard va donner une solution plus directe aux "reproches" faits.

Item 24 : D fait donc comme en C++...

Pour info, IC++ est un bouquin de Matthew Wilson qui adresse des difficults du langages pour montrer des solutions. Il n'exprime pas une critique ngative du langage, mais une constructive. C'est un achat que je ne regrette pas -- mme si je vais avoir des patterns lgrement diffrents des siens pour la DbC en particulier.

@Pierre Dolez. Je ne stocke jamais des octets dans une string, mais dans un vector d'unsigned char plutt. Ce qui lve bien des problmes.
BTW, std::string supporte begin() et end(), ce qui simplifie l'criture.

----------


## Invit

Bonjour Luc Hermite,



> @Pierre Dolez. Je ne stocke jamais des octets dans une string, mais dans un vector d'unsigned char plutt. Ce qui lve bien des problmes.


Je n'ai pas compris ce qu'il ne faut pas faire et ce qu'il faudrait faire.

----------


## pseudocode

> ```
> 
> ```


Bien que je trouve la syntaxe du C plus lisible, le code ci-dessus est typiquement ce qui me fait prfrer l'approche objet.

Ici on transforme mentalement une chaine de caractres en zone linaire d'octets termine par un "0". Bien que cela soit vrai (sous certaines conditions), je prfre que ce genre de dtail soit encapsul dans une classe.

----------


## Invit

Bonjour pseudocode,



> Ici on transforme mentalement une chaine de caractres en zone linaire d'octets termine par un "0".


Je ne suis pas d'accord avec cette phrase. Il aurait fallu dire
"Ici on cre par copie une chaine de caractres,  0 terminal,  l'aide de la fonction c_str(), cre dans ce but."
Pourquoi "sous certaines conditions"? Et quelles sont ces coditions?



> In the Standard C++ Library, a string is actually a template class, named basic_string. The template argument represents the type of character that will be held by the string container. By defining strings in this fashion, the Standard C++ Library not only provides facilities for manipulating sequences of normal 8-bit ASCII characters, but also for manipulating other types of character-like sequences, such as 16-bit wide characters. The datatypes string and wstring (for wide string) are simply typedefs of basic_string, defined as follows:
> 
> typedef basic_string<char> string;
> typedef basic_string<wchar_t> wstring;


La classe basic_string contient un nombre considrable de fonctions membres publiques. Il y a en outre un nombre non ngligeable de fonction non-membre, pour la plupart de surcharge d'oprateurs.

----------


## pseudocode

> Bonjour pseudocode,
> 
> Je ne suis pas d'accord avec cette phrase. Il aurait fallu dire
> "Ici on cre par copie une chaine de caractres,  0 terminal,  l'aide de la fonction c_str(), cre dans ce but."
> Pourquoi "sous certaines conditions"? Et quelles sont ces coditions?


Que ta chaine initiale MBR soit au format ASCII 8-bit et fasse moins de 128 caractres. Si MBR est, par exemple, une url d'un site web japonais, je ne sais pas trop ce qui va se passer... et toi ?

----------


## Invit

Tout  fait d'accord pour ces deux conditions.
Concernant la longueur ; 128 caractres.
Cet exemple concernait une question sur l'impression de chaine de caractre en hexa.
128 fois 5 caractres (ex.: 0x3f) c'est dj pas mal sur une seule ligne.
Mais ceci ne m'empche pas d'utiliser aussi des AnsiString (type assez proche de std::string en Borland)

----------


## Invit

> Ce que tu dcris c'est surtout la fonction "accesseur sur une zone mmoire" des pointeurs. Bref, quelque chose qu'on peut tout a fait proposer dans d'autres langages (C++, Java, ...) sans pour autant que cela soit le coeur du fonctionnement du langage comme dans le C.
> 
> En effet, rien n'empche de dfinir une classe qui manipule une zone mmoire linaire et fournit des accesseurs, de la srialisation, ...
> 
> Le C va plus loin dans le sens o tout ce qui est allou par le langage (les variables, les fonctions) est accessible sous forme de pointeur, un peu  la manire de la reflection. D'ailleurs j'utilise parfois la technique "C Objet" pour disposer du principe des instances dans des programmes en pur C.


L'omnipotence des pointeurs C correspond exactement  ce qu'elle est en assembleur (tout ce qui n'est pas pointeur est direct, en registre ou sous forme de macro texte).
C'est peut-tre elle qui a justifi qu'on remplace le C par autre chose..

En revanche, je me demande s'il est possible d'crire un parser autrement qu'en C. Le parser est au coeur de tous les langages, arbres binaires (huffmann (zip)), des expressions rgulires et, pour certains, de tout le schedule de leurs software (remplace les [boucles infinies / switch case || if...elseif])
Il est rput pour tre l'un des algoritmes les plus solides du gnie logiciel.
En tlcom , remplacer le parser en C exposerait celui qui s'y risque  des problmes de scurit inextricables.  

En fait le parser est partout. Il est mme accessible dans Windows sous forme d'API. 

Le code du parser (une vingtaine de lignes) est une invraisemblable gestion de pointeurs C sur code et sur donnes.

Cela dit, je comprends qu'on prfre moderniser la gestion mmoire pour les applications. Les systmes parser-driven ont des codes difficiles  lire.

Un exemple : le navigateur web ouvre autant de sockets ip qu'il y a d'objets  charger. Chaque socket entre en lecture bloquante et renvoie ce qu'il reoit  un parser configur au pralable par le mime de l'objet lu. Si le serveur est satur, la lecture bloque n'importe o, et surtout l o il ne faut pas... si c'est du javascript, en plein milieu d'une boucle...  Le parser permet de dire ce qui est oprationnel et ce qui ne l'est pas, c'est le parser javascript (tat courant) qui dtermine si la boucle est excutable ou non. Si elle n'est pas compltement charge l'excution javascript sera stoppe au bon endroit jusqu' ce que la routine soit excutable (ds qu'il rencontre l'accolade fermante)..  Il en va de mme pour les gif qui s'affichent partiellement en cours de chargement...   

Le parser est synchrone avec la lecture, lorsqu'elle s'arrte, il s'arrte aussi mais le flux est interprt jusqu'au dernier byte reu ! Aucun autre algoritme ne permet un tel synchronisme. 

En plus de ce processus multithread, il faut pouvoir dtruire tous ces sockets et leur instance de parser si l'utilisateur change de page (pex clic sur url ou history-1,...) 

On peut comprendre que mozilla ou chrome tirent partie de cette synchronicit dont dpend la ractivit du navigateur, et s'il va geler (commandes inactives) jusqu' ce que la page soit charge en totalit ! ce gel serait une hrsie  notre poque, un tel navigateur serait not 0 sur 10 par les'utilisateurs

Nous sommes donc , en tant qu'utilisateurs de navigateurs, trs exigeants sur la fluidit de notre navigateur, fluidit qui dpend directement d'un subtil agencement de C et de C++ !

Entre 94 (mosaic) et 2001 (xp+ie) les mises  jour du socket windows taient constantes, les memory leaks trs frquents et les pages en chargement gelaient mme le desktop !   Winsock32 a mis au moins 7 ans  devenir stable, c'est dire si ces sujets sont sensibles pour le no1 mondial ! (on imagine les moyens mis en oeuvre pour stabiliser tcp/ip).  Sous unix en revanche , les sockets marchent depuis 40 ans et le systme n'a jamais gel  cause de tcpip depuis sa naissance (tcpip a t conu pour unix). Les langages C/C++ ne sont donc absolument pas en cause dans les problmes qu'a rencontr soft qui avait une culture de lecture non bloquante incompatible avec la culture tcpip

----------


## Luc Hermitte

> Je n'ai pas compris ce qu'il ne faut pas faire et ce qu'il faudrait faire.


"std::vector<unsigned char /*ou autre typedef*/> MBR".
Je ne manipules jamais des trucs qui ne sont pas des chaines sous forme de string.
Et si vraiment je veux voir la version hexa d'une string (chose dont je n'ai jamais prouv le besoin jusqu' prsent), j'ai une classe utilitaire sous la main qui m'aurait permis de voir autrement ma chaine:
array_view<byte> view(reinterpret_cast<byte>(&ch[0]), ch.length());

----------


## Invit

> Je ne manipules jamais des trucs qui ne sont pas des chaines sous forme de string.


Oui, c'est votre droit, mais je vous assure qu'on peut trs bien manipuler les deux en toute tranquillit et en toute scurit. 
Petite remarque tout de mme, un std::string[], c'est  dire en utilisant le transtypage de [] est un char, donc sur 1 octet.

----------


## Luc Hermitte

Smantiquement, srd::string est faite pour manipuler des chaines. Pour des tableaux ... bof.
On pourrait aussi utiliser std::basic_string<unsigned char>, mais je crains quelques effets de bords (je ne m'en suis jamais servi)

----------


## pseudocode

> Smantiquement, srd::string est faite pour manipuler des chaines. Pour des tableaux ... bof.
> On pourrait aussi utiliser std::basic_string<unsigned char>, mais je crains quelques effets de bords (je ne m'en suis jamais servi)


Voila, c'est a dont je parlais du "mlange des paradigmes". Ce n'est pas tant le mlange des styles de programmation (la partie syntaxique), mais plus la partie smantique que je trouve complexe. 

L'absence de bonnes pratiques dans ce domaine + l'absence de contraintes du langage donne beaucoup de libert, le prix a payer tant le manque de cohrence possible (probable ?) du rsultat.

----------


## Luc Hermitte

Oui. En C++, la smantique est plus critique qu'ailleurs. C'est un langage dont la parfaite connaissance de la syntaxe ne permet pas de dire que l'on ait compris quoique ce soit.

(mais bon ici ... suis-je le seul  tre gn par l'utilisation de string dans un contexte hors chaine de caractres, ou de ne pas voir l'intrt d'un passage en hexa d'une chaine de caractres ?)

----------


## Invit

Exemple ceci



> 000131 00000305 | 3D 34 35 38 2E 30 32 36 | 20 20 59 3D 31 35 36 2E | =458.026 |   Y=156. | 
> 000141 00000321 | 30 30 30 20 20 5A 3D 35 | 36 2E 30 30 30 0D 0A 52 | 000  Z=5 | 6.000  R | 
> 000151 00000337 | E9 73 75 6C 61 74 20 50 | 74 36 20 28 2D 31 35 2E | sulat P | t6 (-15. | 
> 000161 00000353 | 30 30 30 20 35 32 2E 30 | 30 30 20 2D 34 30 2E 30 | 000 52.0 | 00 -40.0 | 
> 000171 00000369 | 30 30 29 20 58 3D 34 37 | 36 2E 33 30 38 20 20 59 | 00) X=47 | 6.308  Y | 
> 000181 00000385 | 3D 31 34 30 2E 37 38 38 | 20 20 5A 3D 33 32 2E 32 | =140.788 |   Z=32.2 | 
> 000191 00000401 | 32 36 0D 0A 52 E9 73 75 | 6C 61 74 20 50 74 37 20 | 26  Rsu | lat Pt7  | 
> 0001a1 00000417 | 28 2D 31 35 2E 30 30 30 | 20 37 33 2E 35 33 30 20 | (-15.000 |  73.530  | 
> 0001b1 00000433 | 34 2E 31 31 38 29 20 58 | 3D 34 36 32 2E 36 30 30 | 4.118) X | =462.600 |


ou cela



> PNG(0D)
> (0A)(1A)(0A)(00)(00)(00)(0D)


Le premier lit un fichier et imprime par ligne l'ofset hexa, l'ofset dcimal, 16 octets en hexa, et le mmes en caractre.
Le second imprime les caractres jusqu' un sparateur dsign (0D) dans le cas prsent, et  la ligne du dessous, la chaine correspondante en hexa.

Il est certain que si j'ai fait ces outils, c'est que j'en avais besoin.




> Oui. En C++, la smantique est plus critique qu'ailleurs. C'est un langage dont la parfaite connaissance de la syntaxe ne permet pas de dire que l'on ait compris quoique ce soit.


 Je ne comprend pas ce que vous voulez dire par l.




> (mais bon ici ... suis-je le seul  tre gn par l'utilisation de string dans un contexte hors chaine de caractres, ou de ne pas voir l'intrt d'un passage en hexa d'une chaine de caractres ?)


Quant  tre le seul ... certainement pas, mais cela ne signifie pas pour autant que j'ai tord.

----------


## hiura

> (mais bon ici ... suis-je le seul  tre gn par l'utilisation de string dans un contexte hors chaine de caractres, ou de ne pas voir l'intrt d'un passage en hexa d'une chaine de caractres ?)


Non, pas du tout. Mme si le rsultat peut tre quivalent, je prfre utiliser les outils qui ont le plus de sens que de dtourner l'utilit premire d'un autre outil.

----------


## Klaim

> Je ne comprend pas ce que vous voulez dire par l.


Qu'on peut techniquement faire n'importe quoi, sans que ce soit une bonne "ide".

Comme pour ton exemple.




> (mais bon ici ... suis-je le seul  tre gn par l'utilisation de string dans un contexte hors chaine de caractres, ou de ne pas voir l'intrt d'un passage en hexa d'une chaine de caractres ?)


De mme. 
Ca m'apparait comme un "code smell".

----------


## Luc Hermitte

> Exemples [...]
> 
> Le premier lit un fichier et imprime par ligne l'ofset hexa, l'ofset dcimal, 16 octets en hexa, et le mmes en caractre.
> Le second imprime les caractres jusqu' un sparateur dsign (0D) dans le cas prsent, et  la ligne du dessous, la chaine correspondante en hexa.
> 
> Il est certain que si j'ai fait ces outils, c'est que j'en avais besoin.


Je n'en doute pas un seul instant. Mais ... j'ai dj un outil trs bien pour cela : xxd qui s'intgre nativement  vim (c'est un sous-projet)  ::): 
Par contre, je persiste que pour ce genre d'applications, ce que je vois, ce sont des fichiers binaires. Et j'vite toujours de manipuler des octets via des char, mme s'il s'agit du type utilis dans l'interface native des fonctions d'I/O du C et du C++. Et dans cette continuit, je ne manipule pas des std::string, mais des std::vector qui m'offrent une interface plus bas niveau, ou plus exactement une smantique plus proche de celle des tableaux, d'octets ici.




> Je ne comprends pas ce que vous voulez dire par l.


En fait, c'est un rsum rapide de mes ides sur le sujet.
Une bonne utilisation du C++ requiert de distinguer les smantiques d'entit et de valeur (cf FAQ), de comprendre des aspects de conception OO (ou comment bien choisir son hritage parmi 3), etc. Ce n'est pas parce que l'on connait la syntaxe que l'on va comprendre que copier des classes tires de hirarchies ne sert  rien (hormis complexifier le code et faire perdre du temps  tout le monde), ou que les tableaux de dgradation des accs (pri, pro, pub) sont moins importants que la dichotomie "utilis en place de" Vs "importation de code".

----------


## gl

> (mais bon ici ... suis-je le seul  tre gn par l'utilisation de string dans un contexte hors chaine de caractres, ou de ne pas voir l'intrt d'un passage en hexa d'une chaine de caractres ?)


Non.




> Le premier lit un fichier et imprime par ligne l'ofset hexa, l'ofset dcimal, 16 octets en hexa, et le mmes en caractre.


Mais justement dans le cas d'un dump comme ici, on ne cherche gnralement pas  afficher en hexadcimal le contenu d'une chane de caractre mais  afficher le contenu d'un tableau de byte sous sa reprsentation hexadcimal et, pour les valeurs pour lesquelles cela  un sens, le caractre correspondant  cette valeur.

Pour le second exemple, je ne vois pas vraiment le cas concret qui est derrire donc je ne serais pas aussi affirmatif, mais vu le contenu de l'exemple, il me semble que c'est galement le cas.

----------


## Invit

Pour les deux exemples, il est bien vident, en tout cas pour moi, que ce type d'impression n'a aucun intrt pour les fichiers choisis. J'ai pris le premier venu.
Pour expliquer le type d'utilisation, dans l'un et l'autre cas, quand on a un fichier binaire qui reprsente des articles, exemple shp, dbf, mid et Cie, si vous connaissez une meilleure mthode pour essayer de les comprendre, je suis preneneur (mais voila que j'essaye de me justifier, horreur ::mouarf:: )
De toute faon, il n'y a que moi qui puisse juger si cette mthode d'affichage est justifie.

Concernant l'impression en Hexa. Cette question a t pose sur un forum de developpez.com (mais un autre sous-forum que celui-ci) Cet exemple m'a paru intressant dans ce dbat "dfauts du C++". Mais cela ne va pas plus loin. Tout le monde a bien remarqu que j'avais mis les deux codes et que je n'avais ajout aucun commentaire : je n'ai pas pris parti.
Mais apparemment, cette comparaison n'a pas plu  tout le monde. J'ai demand des exemples pour complter les affirmations, je n'en ai pas eu.

Enfin, il faudrait m'expliquer la diffrence entre 



> afficher en hexadcimal le contenu d'une chane de caractre


et



> afficher le contenu d'un tableau de byte sous sa reprsentation hexadcimal


Cela sous-entendrait-il qu'une chaine de caractre n'est pas un tableau de bytes ?
De toute faon, comme je l'ai dit au dbut, cet outil est utilis pour visualiser des fichiers, j'ai simplement rpondu  une observation : afficher en hexa ne sert  rien.

----------


## alexis b

> C'est justement ma critique personnelle depuis le dbut. Je prfrerai que la smantique des oprateurs prsents "de base" soit inaltrable par le programmeur.
> 
> [...] Je le trouve juste trop "permissif" a mon gout


Non justement, a c'est trs bien...

----------


## gl

> Enfin, il faudrait m'expliquer la diffrence entre 
> 
> 
> 
> 
> 			
> 				afficher en hexadcimal le contenu d'une chane de caractre
> 			
> 		
> ...


Smantiquement ce n'est pas du tout la mme chose, tu ne manipules pas le mme concept dans les deux cas.
Qu'un langage comme le C utilise un tableau de char termin par un 0 pour reprsenter une chane de caractres n'est qu'un choix d'implmentation. Ca ne signifie pas qu'une chane de caractres et un tableau de bytes sont conceptuellement identiques.

En C la diffrence de smantique entre ces deux notions est certes peu flagrante dans le conteneur utilis (en gros simplement char vs. unsigned char) mais transparait par contre dans les fonctions de manipulations (utiliser les fonctions strXXXX sur autre chose qu'une chane de caractres n'est gnralement pas une bonne ide).
En C++ la diffrence est plus vidente puisque des types (std::string, std::wstring) existent pour grer les chanes de caractres alors qu'un tableau de byte sera plutt reprsent par un std::vector<unsigned char> ou par un boost::array<unsigned char, X>.

----------


## alexis b

> (mais bon ici ... suis-je le seul  tre gn par l'utilisation de string dans un contexte hors chaine de caractres[...])


1 char = 1 byte  :;):  . Donc utiliser le type char pour les tableau de bytes est tout  fait normal...

Le mieux est cependant d'utiliser une classe adquate (cf. les bytes arrays in Qt), cela simplifira largement les choses  :;):  .




> Ca ne signifie pas qu'une chane de caractres et un tableau de bytes sont conceptuellement identiques.


Fondamentalement, ils le sont  :;):  .




> utiliser les fonctions strXXXX sur autre chose qu'une chane de caractres n'est gnralement pas une bonne ide


Il faut prciser la taille, alors que pour les chaines de caractres, ce n'est pas ncessaire (c'est pour cela que les fonctions dont vous parlez ont toujours 2 versions (dont une permet de spcifier la taille  :;): )).

----------


## gl

> 1 char = 1 byte  . Donc utiliser le type char pour les tableau de bytes est tout  fait normal...
> 
> Le mieux est cependant d'utiliser une classe adquate (cf. les bytes arrays in Qt), cela simplifira largement les choses  .


Ce n'est pas l'usage de char qui est choquant ici (quoique unsigned char serait certainement plus appropri) mais le fait d'utiliser une chane de caractre.




> Fondamentalement, ils le sont  .


Ben justement non. En C, une chane de caractre est reprsent par un tableau de char, mais ce sont bien deux notions diffrentes (tout tableau de char n'est pas une chanes de caractres et d'autres langages implmentent les chanes d'une autres manire).

Il ne faut pas confondre le concept et la reprsentation.




> Il faut prciser la taille, alors que pour les chaines de caractres, ce n'est pas ncessaire (c'est pour cela que les fonctions dont vous parlez ont toujours 2 versions (dont une permet de spcifier la taille )).


C'est plus compliqu que a. Il faut certes fournir la taille mais il faut surtout utiliser une fonction n'ayant pas de smantique de chane. 
Tu peux prendre strncpy() qui a bien la taille en paramtre, tu risques d'avoir du mal  copier un tableau de byte qui contient un 0.

Et au passage les fonctions de manipulations de chane de caractres n'ont pas toutes une version dont on spcifie la taille, je n'ai par exemple pas encore vu de fonction strnlen() (qui aurait amha un intrt assez limit), ou plus srieusement strstr, strchr, etc.

----------


## alexis b

Je maintiens que le type char peut tre utilis aussi bien pour les chaines de caractres que pour du code octet (aussi appel byte code).




> Tu peux prendre strncpy() qui a bien la taille en paramtre, tu risques d'avoir du mal  copier un tableau de byte qui contient un 0.


Vous connaissez memcpy ? C'est  a que je pensais (en l'occurence  :;): ).




> Ben justement non. [...]
> 
> Il ne faut pas confondre le concept et la reprsentation.


Je maintiens que fondamentalement, c'est la mme chose  :;):  .

1 caractre = 1 byte = 1 char (si vous prfrez qu'on dise les choses ainsi ^^)




> quoique unsigned char serait certainement plus appropri


Pour tre trs complet, on pourrait rajouter 1 char = 1 unsigned char (c'est exactement chose, et la reprsentation en mmoire est la mme  :;): ).

1 char gal  -1, c'est aussi 1 unsigned char gal  255 (ce qui nous amne  l'quation -1 = 255 ^^ (et ainsi de suite)).

----------


## koala01

> Vous connaissez memcpy ? C'est  a que je pensais (en l'occurence ).


Justement, memcpy ne travaille qu'au niveau de la mmoire, sur des... bytes.

C'est, justement, ce que gl essaye de mettre en vidence: si memcpy et str(n)cpy existent tous les deux, ce n'est pas pour faire joli, ni pour avoir le plaisir de se compliquer la vie en devant choisir l'une des deux:

str(n)cpy va considrer le premier caractre nul '\0' comme... la fin de la chaine significative, et donc arrter la copie des donnes.

memcpy va considrer un byte nul comme... ce qu'il est : un byte dont la valeur est 0, qui peut tre une valeur tout  fait valide et non diffrente de 1 ou de 251.



> Je maintiens que fondamentalement, c'est la mme chose  .


Non...

C'est toujours un problme de smantique.

une chaine de caractres reprsente... une succession de caractres imprimables susceptible de prendre une signification pour celui qui la lit.

un tableau de byte peut n'avoir strictement aucune signification particulire pour l'humain qui l'aurait devant les yeux tout en ayant une signification bien clair pour le programme qui l'utilise, par exemple, parce que 32 bytes pourraient en ralit reprsenter... 8 valeur numriques codes chacune sur 4 bytes.



> 1 caractre = 1 byte = 1 char (si vous prfrez qu'on dise les choses ainsi ^^)


on est bien d'accord qu'un caractre, c'est un char et qu'un char a la mme taille qu'un byte, c'est d'ailleurs clairement dit dans la norme.

Mais un byte peut parfaitement tre autre chose qu'un caractre: cela peut, tout simplement, reprsenter une valeur numrique comprise dans la plage de valeurs reprsentables grce aux nombre de bits qui composent le byte (tu remarquera d'ailleurs que je ne prcise pas ce nombre de bits, essentiellement parce qu'il n'est pas forcment gal  8  :;): )



> Pour tre trs complet, on pourrait rajouter 1 char = 1 unsigned char (c'est exactement chose, et la reprsentation en mmoire est la mme ).
> 
> 1 char gal  -1, c'est aussi 1 unsigned char gal  255 (ce qui nous amne  l'quation -1 = 255 ^^ (et ainsi de suite)).


La reprsentation en mmoire est identique, la valeur que tu donne  cette reprsentation est diffrente.

Et c'est bien l tout le problme:

Quand tu travailles sur une chaine de caractres, tu va t'attendre  avoir:
une ou plusieurs des 26 lettres minusculesune ou plusieurs des 26 lettres majusculesun ou plusieurs des dix symboles reprsentant les chiffresun ou plusieurs caractres plus ou moins sotrique, comme les symboles mathmatiques, montaires, signe de ponctuation, espace ou autres caractres accentus.
Mais c'est oublier un peu vite que le premier caractre reprsentable a la valeur 32 (en dcimal) et reprsente l'espace, et qu'il y a donc aussi les caractres ayant les valeurs comprises entre 0 et 31 qui ne sont absolument pas reprsentables (dont le 0 qui... reprsente la fin d'une chaine de caractres  sa premire occurrence).

C'est aussi oublier un peu vite que le caractre nul peut aussi tre... n'importe quel byte d'un type primitif cod sur plus d'un byte et donc, simplement, tre  considrer comme... 8 bits mis  0 (du moins, sur les architectures "grand public" classiques)

C'est pour le cas o il ne faut, justement, pas considrer un byte comme s'il s'agissait d'office d'un caractres qu'il faut... se donner la possibilit d'en maintenir une collection autrement que sous la forme d'une chaine de caractres.

Toute manipulation de fichier au format "binaire" mrite que l'on fasse cette distinction  :;):

----------


## pseudocode

> 1 caractre = 1 byte = 1 char (si vous prfrez qu'on dise les choses ainsi ^^)


Non. il y a un glissement smantique ici entre caractre (entit) et byte/char (reprsentation).

Un caractre ASCII-7 bits est stockable sur 1 byte, ou sur 1 char (bref sur un type de 8 bits). Un caractre ASCII-8 bits galement. Et un caractre UTF8 8 bits aussi. Et aussi un entier entre 0 et 255. Ou une entier entre -128 et +127.

Pourtant tous ces types ne sont pas gaux entre eux, et donc pas interchangeables.

Assimiler chaine de caractre et tableau de byte/char est un raccourci technique valable en C (seulement dans certaines conditions) parce qu'il n'existe pas de frontire smantique entre l'entit et sa reprsentation interne.

Mais c'est nettement moins le cas dans des langages objets qui existent prcisment pour "capturer" la smantique de l'entit et la sparer de sa reprsentation.

En objet (et donc en C++ objet), un itrateur sur une instance de chaine de caractre renvoie une instance de caractre. Alors qu'un itrateur sur une instance de tableau d'octet renvoie une instance d'octet. Gommer la diffrence smantique en sachant (ou supposant) qu'ils utilisent la mme reprsentation interne est un gros risque.

----------


## alexis b

> Justement, memcpy ne travaille qu'au niveau de la mmoire, sur des... bytes.
> 
> C'est, justement, ce que gl essaye de mettre en vidence: si memcpy et str(n)cpy existent tous les deux, ce n'est pas pour faire joli, ni pour avoir le plaisir de se compliquer la vie en devant choisir l'une des deux


Je pense que vous devriez relire la discussion, j'ai clairement indiqu la fonction memcpy comme tant la fonction adquate pour les tableaux de bytes...




> un byte dont la valeur est 0, qui peut tre une valeur tout  fait valide et non diffrente de 1 ou de 251.


0 = 1 = 251 ?

----------


## koala01

> 0 = 1 = 251 ?


Au temps pour moi... j'aurais du dire " l'instar de 1 ou de 251"... 

Bref, une valeur numrique tout  fait "classique"  ::D:

----------


## Luc Hermitte

> 1 char = 1 byte  . Donc utiliser le type char pour les tableau de bytes est tout  fait normal...


Mais pas un octet que je m'attends  aller de 0  255. A cause du signe.
Quand on veut stocker nos octets dans des chars, il faut rapidement jongler avec des reinterpret_cast pour afficher des valeurs hexa entre 0x00 et 0xff, ou simplement manipuler des octets variant entre 0 et 255.
Soit le code que Pierre Dolez nous avait initialement montr.

Si je ne m'abuse, j'avais signal que je voyais une maladresse dans la mesure o l'on cherchait  afficher des chaines (stockant des squences de char) en version hexa, alors qu'au fond dans notre tte on manipule des squences d'unsigned char. Maladresse smantique qui introduit ensuite une complexit dans le code

Code qui est dj suffisamment verbeux comme a grce aux streams (pour passer en 2 caractres hexa). C'est sr que la version printf du C est plus lgre, mais au prix de code non DRY (on rpte le type) et non scuris (on a vite fait de balancer une variable de type incompatible, voire non-POD (comme une string)). J'ai l une prfrence pour des choses comme boost::format.

----------


## alexis b

> ```
> 
> ```


strcpy ne peut pas prendre une variable de type unsigned char [] (il faudrait la dclarer comme tant de type char []). De toute faon, il est inutile de faire une copie. A noter aussi que 'c' est un pointeur  :;):  .

En tant que grand professionnel, je vous donne le corrig  ::mrgreen::  .




> _for (const char *c = MBR.c_str();*c; c++) printf("%2x ",(unsigned char) *c);
> printf("\n");_


Alors, c'est qui le maitre du C++ ? Enfin c'est presque du C en l'occurence  :;):  .

----------


## pseudocode

> Alors, c'est qui le maitre du C++ ? Enfin c'est presque du C en l'occurence  .


C'est mme compltement du C, pour preuve l'utilisation de *c_str()*.  ::D:

----------


## Invit

Bonjour Alexis_b
Je pense que si on veut compresser le code, ce serait plutt cela, 


```
for (unsigned char *c = (void*)MBR.c_str(); c; c++) printf("%2x ", c);
```

Mais, j'avoue n'avoir essay ni l'un ni l'autre.

Ceci dit, je suis rellement en admiration. Si je rsume bien ce que j'ai compris " un byte et un char, pour la machine c'est la mme chose, mais puisque a peut ne pas reprsenter la mme chose on va les traiter diffremment, tant pis si a rend les programmes compltement indigestes et illisibles."
A plusieurs reprises le terme "comprendre" a t employ. Habituellement, je comprends assez facilement, mais j'avoue que j'ai vu beaucoup plus d'affirmations que d'explications, et en tout cas jamais d'exemple.
Bonne journe.

----------


## pseudocode

> Ceci dit, je suis rellement en admiration. Si je rsume bien ce que j'ai compris " un byte et un char, pour la machine c'est la mme chose, mais puisque a peut ne pas reprsenter la mme chose on va les traiter diffremment, tant pis si a rend les programmes compltement indigestes et illisibles."
> A plusieurs reprises le terme "comprendre" a t employ. Habituellement, je comprend assez facilement, mais j'avoue que j'ai vu beaucoup plus d'affirmations que d'explications, et en tout cas jamais d'exemple.
> Bonne journe.



Le raisonnement est inverse : "Vu que ca ne reprsente pas la mme chose, on ne va pas utiliser le mme type (byte, char ou objet)"

Les caractres d'une chaine de texte :


```

```

(je sais, il n'y a pas encore de foreach en C++. C'est pour l'exemple  ::aie:: )

Les octets d'un tableau d'octets


```

```


Les lments d'une chaine de char  zro terminal


```

```

----------


## alexis b

> C'est mme compltement du C, pour preuve l'utilisation de *c_str()*.


Non justement, c_str() est une fonction du C++ (elle fait mme partie de la classe string), donc elle prouve l'inverse  :;):  .




> Bonjour Alexis_b
> Je pense que si on veut compresser le code, ce serait plutt cela, 
> 
> 
> ```
> for (unsigned char *c = (void*)MBR.c_str(); c; c++) printf("%2x ", c);
> ```


Il y a encore quelques erreurs (et je crois que mon code est incompressable  :;): ). Aller je te mets quand mme 8 / 10 ^^




> A plusieurs reprises le terme "comprendre" a t employ. Habituellement, je comprend assez facilement, mais j'avoue que j'ai vu beaucoup plus d'affirmations que d'explications, et en tout cas jamais d'exemple.
> Bonne journe.


A toi aussi  :;):  .

----------


## atttchoum

> Non justement, c_str() est une fonction du C++ (elle fait mme partie de la classe string), donc elle prouve l'inverse  .


c_str() te permet d'utiliser une chaine de caractres " la sauce C".
a montre gnralement que tu vas faire du C.

----------


## alexis b

> c_str() te permet d'utiliser une chaine de caractres " la sauce C".
> a montre gnralement que tu vas faire du C.


Essaye de compiler le code avec un compilateur C, a pourra pas fonctionner  :;):  . CQFD

----------


## Davidbrcz

> Essaye de compiler le code avec un compilateur C, a pourra pas fonctionner  . CQFD


On est d'accord, c'est du C++ SAUF qu'elle existe pour fournir un acces en lecture vers l'implementation interne de la chaine (un char*)  souvent dans le but de pouvoir utiliser des fonctions qui attendent des char* qui sont (a moins de tomber sur un fou qui utilise ca en C++) tirees du C.

----------


## alexis b

> On est d'accord, c'est du C++


Trs bien  ::ccool::  .




> SAUF qu'elle existe pour fournir un acces en lecture vers l'implementation interne de la chaine (un char*)  souvent dans le but de pouvoir utiliser des fonctions qui attendent des char* qui sont (a moins de tomber sur un fou qui utilise ca en C++) tirees du C.


Je n'ai jamais dit le contraire ^^

PS : bien que rien n'empche d'utiliser le type char (mme en C++) dans des algorithmes qui ncessiterait d'tre trs optimiss.

----------


## pseudocode

> Je n'ai jamais dit le contraire ^^
> 
> PS : bien que rien n'empche d'utiliser le type char (mme en C++) dans des algorithmes qui ncessiterait d'tre trs optimiss.


Bah c'est possible, mais ca participe au mlange des genres que je trouve critiquable. Je prfrerai que le code "pur C" soit clairement dissoci du reste, par exemple avec des marques de bloc, comme pour l'assembleur.

----------


## alexis b

> Bah c'est possible, mais ca participe au mlange des genres que je trouve critiquable. Je prfrerai que le code "pur C" soit clairement dissoci du reste, par exemple avec des marques de bloc, comme pour l'assembleur.


Il est possible de faire des algorithmes trs optimiss en utilisant les char, sans passer par la moindre fonction lorsque l'on utilise ces valeurs (donc on n'a pas besoin d'utiliser les fonctions propres au langage c).

Dans ces conditions, le type char faisant partie intgrante du C++, cela me semble tout  fait normal  ::ccool::  .

----------


## pseudocode

> Il est possible de faire des algorithmes trs optimiss en utilisant les char, sans passer par la moindre fonction lorsque l'on utilise ces valeurs (donc on n'a pas besoin d'utiliser les fonctions propres au langage c).
> 
> Dans ces conditions, le type char faisant partie intgrante du C++, cela me semble tout  fait normal  .


Le type "char" je dis pas. Mais la post-incrmentation du pointeur (et son possible dpassement de la zone mmoire) c'est pas trs C++ Objet.

----------


## Luc Hermitte

Un pointeur est un itrateur trivial. C'est trs C++ aussi.

----------


## pseudocode

> Un pointeur est un itrateur trivial. C'est trs C++ aussi.


Bah, c'est un type natif, comme 'int' ou 'char' et donc pas une instance d'objet. 

Pourtant ils sert (ou peut servir)  accder  un objet, ce que ne peuvent pas faire les autres types natifs. C'est donc assez hybride je trouve.

----------


## Luc Hermitte

Et ? Toute la bibliothque standard du C++ repose sur le principe  que OO n'est pas une finalit.

----------


## pseudocode

> Et ? Toute la bibliothque standard du C++ repose sur le principe  que OO n'est pas une finalit.


hum...  ::koi:: 

Pour moi la STL est surtout base des concepts de modlisation et, pour le cas qui nous intresse ici, le *Input Iterator*. 

Toujours dans ma vision des choses, en C++/STL le type "char*" est un *itrateur* sur le type natif 'char'. Alors qu'en C c'est un *pointeur* sur une zone mmoire contenant un 'char'.

Si, au final, l'implmentation est la meme, pour moi ce n'est pas la meme smantique. En C, la valeur du pointeur  une signification (= c'est une adresse mmoire), alors qu'en C++ il n'a pas besoin d'en avoir : tout ce qui compte c'est que ce type permette de faire une itration.

D'ailleurs, bien que dans l'exemple ces deux types sont utiliss pour faire une itration, plusieurs personnes ici semblent voir une diffrence conceptuelle entre un "char*" et un "vecteur de char".

----------


## Invit

Bonsoir,
J'ai vraiment l'impression qu'on s'loigne de la finalit d'un langage qui consiste  procurer une interface entre l'homme et la machine.
Par manque de comptence, je ne critique pas les options (et non pas les possibilits) du C++, mais dans la mesure o cela provoque de telles discussions, je me demande si ces limitations -cad C diffrent de C++ et vice versa- ont vraiment une justification.
Les diffrences de smantique (j'adore ce terme) s'adressent et concernent les individus et non la machine. Par la machine la seule chose qui est une ralit est qu'un bit est activ ou non, et qu'un mot (un octet) est compos de 8 bits.
Ceci est mon avis.
Bonne nuit.

----------


## _skip

Pour recadrer un peu le dbat, quelles sont nos chances d'un meilleur C++? 
On a pu constater que le processus de normalisation est compliqu et que les cycles d'volution sont de fait, plutt longs (voir C++1x).

Actuellement j'ai l'impression que le C++ est un peu paralys dans son volution par sa volont d'tre source compatible C et surtout  cause de l'immensit des bases de codes existantes.
Y'a-t-il des gens ici qui pensent qu'il serait prfrable pour le comit de "geler" C++ et de repartir sur un successeur non source compatible (D++) en faisant table rase des vieilles casseroles?

----------


## hiura

> Pour recadrer un peu le dbat, quelles sont nos chances d'un meilleur C++? 
> On a pu constater que le processus de normalisation est compliqu et que les cycles d'volution sont de fait, plutt longs (voir C++1x).
> 
> Actuellement j'ai l'impression que le C++ est un peu paralys dans son volution par sa volont d'tre source compatible C et surtout  cause de l'immensit des bases de codes existantes.
> Y'a-t-il des gens ici qui pensent qu'il serait prfrable pour le comit de "geler" C++ et de repartir sur un successeur non source compatible (D++) en faisant table rase des vieilles casseroles?


Il est bien vident que je ne suis pas un expert et de ce fait mon avis peut tre erron mais il me semble aussi que partir sur une nouvelle base aurait de bons cts.
Mais est-ce le rle du C++ d'voluer vers un C far away (hohoho,   ::aie:: ) / D++ ? Ou est-ce plutt le rle d'un nouvel arrivant (le D par exemple) ? Je sais pas.

----------


## Klaim

> Pour recadrer un peu le dbat, quelles sont nos chances d'un meilleur C++? 
> On a pu constater que le processus de normalisation est compliqu et que les cycles d'volution sont de fait, plutt longs (voir C++1x).
> 
> Actuellement j'ai l'impression que le C++ est un peu paralys dans son volution par sa volont d'tre source compatible C et surtout  cause de l'immensit des bases de codes existantes.
> Y'a-t-il des gens ici qui pensent qu'il serait prfrable pour le comit de "geler" C++ et de repartir sur un successeur non source compatible (D++) en faisant table rase des vieilles casseroles?


Non.
Les deux ont  des diffrences qui me semblent trop importantes pour qu'on en laisse un pour l'autre.

Par contre un C++ 2.0 qui aurait principalement comme absence de contrainte lie au C serait je pense plus efficace. Surtout si on en profite pour virer tout ce qui est considr comme mauvais dans le C++11 mais qu'on ne pouvais pas enlever a cause de la rtrocompatibilit. Nettoyer le language des expressions redondantes aussi serait pas mal (par exemple ne plus avoir qu'une seule syntaxe pour les typedef, plutot using que typedef d'ailleurs. )

----------


## befalimpertinent

Difficile d'tre d'accord avec a tant donn que je penses que la force du C++ est justement cette ("quasi") rtrocompatibilit. Ce qui fait que le C++ soit  l'heure actuel toujours aussi prsent dans l'industrie tient justement au fait qu'un code crit il y a 20 ans compile encore avec les compilos actuels (ok a 2-3 bidouilles prts parfois mais du uniquement au laxisme des compilos de l'poque). Casser a c'est se tir une balle dans le pied (ou alors par piti ne l'appeler plus C++ mais D quelque chose  ::P:  ).
Encore aujourd'hui je ne suis pas loin de penser que quand on veut faire du dveloppement un peu srieux qui tienne la route et surtout la dure, le C++ doit tre privilgier, au moins on peut avoir l'espoir qu'il compilera encore dans 15 ans.

En dfinitive marquer certaines pratiques en "deprecated" pourquoi pas, les interdire non.

----------


## Florian Goo

> Actuellement j'ai l'impression que le C++ est un peu paralys dans son volution par sa volont d'tre source compatible C et surtout  cause de l'immensit des bases de codes existantes.
> Y'a-t-il des gens ici qui pensent qu'il serait prfrable pour le comit de "geler" C++ et de repartir sur un successeur non source compatible (D++) en faisant table rase des vieilles casseroles?


J'en rve !

D'autant plus que (comme je l'ai dj dit ici) on pourrait continuer  profiter de la base de code existante  coups de :


```

```

----------


## Klaim

> Difficile d'tre d'accord avec a tant donn que je penses que la force du C++ est justement cette ("quasi") rtrocompatibilit. Ce qui fait que le C++ soit  l'heure actuel toujours aussi prsent dans l'industrie tient justement au fait qu'un code crit il y a 20 ans compile encore avec les compilos actuels (ok a 2-3 bidouilles prts parfois mais du uniquement au laxisme des compilos de l'poque). Casser a c'est se tir une balle dans le pied (ou alors par piti ne l'appeler plus C++ mais D quelque chose  ).
> Encore aujourd'hui je ne suis pas loin de penser que quand on veut faire du dveloppement un peu srieux qui tienne la route et surtout la dure, le C++ doit tre privilgier, au moins on peut avoir l'espoir qu'il compilera encore dans 15 ans.
> 
> En dfinitive marquer certaines pratiques en "deprecated" pourquoi pas, les interdire non.


On est d'accord que la compatibilit avec le C et la rtrocompatibilit globale du language est une force.

Cela n'empche pas qu'une nettoyage du language, dans une version diffrente (je parle d'un fork en gros, pas d'une suite), qui serait rtro compatible avec la dernire norme C++ mais pas avec les prcdentes serait aussi interessante et permettrais de se baser sur la base de code en C++03 qui n'aurait pas de "C pure".

Cela dit c'est une ide qui n'est pas rflchie a l'extreme, il n'y a pas un commit de spcialiste drrire.  ::):

----------


## raphamil

> un autre que je trouve plus problmatique s'admire sur la signature du main standard : int main(int argc, char **argv) et ses drivs avec le char* argv[], on a une bibliothque standard avec quand mme pas mal de choses MAIS pour l'entre d'un programme on rgresse du c++ vers le c; pour rester dans le c++ quelque chose du style de int main(vector<string> args) aurait t plus appropri selon moi.




```
std::vector<std::string> args(argv, argv + argc);
```

----------


## Invit

Oui, effectivement, d'ailleurs, pourquoi continuer  faire simple alors qu'on pourrait faire compliqu?
Autre question, vous arrive-t-il souvent de faire des programmes qui se lancent en ligne de commande avec des paramtres? Moi, a fait bien une vingtaine d'annes que je ne travaille plus qu'avec des fentres  ::P:  
Donc, mon avis, laissez le C++ comme il est. Il y une quantit d'autres langages et pour tous les gots. Au moins, celui-l, il a fait ses preuves.

----------


## hiura

> Oui, effectivement, d'ailleurs, pourquoi continuer  faire simple alors qu'on pourrait faire compliqu?
> Autre question, vous arrive-t-il souvent de faire des programmes qui se lancent en ligne de commande avec des paramtres? Moi, a fait bien une vingtaine d'annes que je ne travaille plus qu'avec des fentres  
> Donc, mon avis, laissez le C++ comme il est. Il y une quantit d'autres langages et pour tous les gots. Au moins, celui-l, il a fait ses preuves.


a m'est arriv il y a pas si longtemps que a. Du coup un petit coup de boost et c'est goal.

----------


## Klaim

> Autre question, vous arrive-t-il souvent de faire des programmes qui se lancent en ligne de commande avec des paramtres? Moi, a fait bien une vingtaine d'annes que je ne travaille plus qu'avec des fentres


C'est orthogonal : quasiment tous les jeux vidos sur PC/windows que je fais (donc fenetrs) ont des paramettres d'execution.

C'est un peu naif de supposer que ce n'est pas utile parceque toi tu n'en as plus besoin. Mme la plupart des applications windows ont des paramtres, c'est juste que toi tu n'as jamais eu a les utiliser.
Ne serait-ce que les compilateurs. Et les solutions de control de source. (les gui qui vont avec sont construits par dessus - si ces solutions n'taient pas en ligne de commande de base, a aurait compliqu les choses)
Et je te parle mme pas des applications sous unix-like.

----------


## Florian Goo

En effet. Firefox lui-mme a des options d'excution trs pratiques (gestion de profils multiples).

Il est galement trs utile de faire des petits programmes en ligne de commande pour tester une bibliothque en dveloppement (tests de non-rgression, dmonstration, tout a).

----------


## Invit

Bon, je vois que ce problme de paramtres du main est trs proccupant ::mouarf:: 
J'imagine bien que cela doit tre trs traumatisant d'avoir un programme o on a banni tous les char*, les new, o on a remplac les simples transtypage par des <dymamic_cast>  etc et qu'il puisse exister encore une ligne o il reste cette horrible chose char* d'autant plus qu'on lui en rajoute un (*) supplmentaire.
C'est d'autant plus nervant que la syntaxe de cette ligne est la mme qu'en C, qu'on a russi  rendre presque tout "diffrent du C", au prix de relles complications, il est vrai, mais l, chec total  ::D: .
Comme je devinais que ce devait tre trs important pour certains, hier j'ai pens  prciser la mthode, suggre par raphamil, pour arranger cela :


```

```

 Et l on aura une fonction parfaitement propre, saine et beaucoup plus claire : MyMain

Pour essayer d'tre un peu plus srieux et plus constructif, serait-il possible de dresser un rsum des points correspondants au sujet pos, c'est  dire : "Quel est pour vous le dfaut le plus gnant en C++" 
Moi, je mettrais comme premire qualit : parce qu'il traite toutes les instructions, la logique, l'organisation etc. du C (Oh pardon, on demande les dfauts  ::oops::  )

Rponse  Florian.
Bien sr qu'on crit des programmes en ligne de commande. Ma question,  propos de la dernire fois que c'est arriv, j'aurais pu la poser de cette faon : Quel pourcentage de lignes de code cela reprsente-t-il ?  Traduction : est-ce un dfaut du C++ pour que cela vaille le coup d'en parler ici?
Personnellement, j'adore la technique qui consiste  trouver une objection  un interlocuteur pour tre sr de pouvoir viter d'aborder le sujet principal.

----------


## Klaim

Vu qu'il y a une bibliothque de boost consacre au sujet, je suppose que oui.

Sinon personellement je prfre ne pas drsser de liste parceque je ne sais pas encore clairement a quel point la nouvelle norme simplifie les choses. Cela dit, la standardisation d'un systme de module (entre autre pour acclrer les compilations) et le problme du temps trop long pour implmenter le standard seraient dans le haut de ma liste des problmes.
J'ajouterais aussi l'absence des Concepts mais bon c'est un sujet un peu difficile a discuter actuellement, tant qu'il n'y aura pas une nouvelle tentative d'implmentation.

----------


## Florian Goo

> Rponse  Florian.
> Bien sr qu'on crit des programmes en ligne de commande. Ma question,  propos de la dernire fois que c'est arriv, j'aurais pu la poser de cette faon : Quel pourcentage de lignes de code cela reprsente-t-il ?  Traduction : est-ce un dfaut du C++ pour que cela vaille le coup d'en parler ici?
> Personnellement, j'adore la technique qui consiste  trouver une objection  un interlocuteur pour tre sr de pouvoir viter d'aborder le sujet principal.


Ah non, y'a mprise. Pas de tentative de manipulation de ma part, je me suis juste laiss emport par le hors-sujet.

Pour moi, la raison d'existence du main C-style est surtout historique, la STL tait apparue plus tard dans l'volution du C++.
Autrement je ne trouve pas que ce soit un norme problme. Au contraire, c'est mme mieux comme a : pas de cration d'objets donc pas d'overhead si ce n'est pas dsir. Et si on le souhaite, une petite ligne de code suffit  crer un vector de strings.
C'est dans l'esprit du C++ : on ne paie pas pour ce qu'on n'utilise pas et on peut redescendre aussi bas niveau qu'on en a envie/besoin.

----------


## davcha

A noter que strnlen existe et a pour principale utilit de produire un code sr, comme toutes les fonctions strn*.

Sinon, y'a que moi qui trouve que l'un des grands dfauts du C++ est d'tre semblable aux navigateurs web il y a quelques annes ?
D'ailleurs, la discussion sur les strings vs tableaux de byte en tmoigne : c'est un vritable bourbier o la smantique est totalement maltraite, battue, voire mme ignore.

Srieusement, qui n'a jamais connu un gamin sorti d'cole qui se prend pour un programmeur super-cool super-balaise, tout en produisant du code C/C++ (surtout C++) illisible ?

Pour moi, c'est a LE gros dfaut de C++ : c'est un langage qui a le cul entre deux chaises. Proche de la machine, mais abstrait quand mme...
Faut savoir ce qu'on veut. Soit on manipule des concepts, soit on manipule des bits. Mais on mlange pas tout sans arrt, sinon, bonjour la prise de tte.

----------


## ac_wingless

Les dfauts qui me (je reconnais le biais induit par mon domaine de travail, l'embarqu industriel) gnent le plus sont, dans l'ordre:

1 - la difficult de compilation du langage, qui a pour consquences:1a) les petites diffrences entre comportements des compilateurs, d'o l'impossibilit de gnraliser dans des grands projets les techniques avances du C++ ou de Boost
1b) le manque de ractivit/qualit des outils IDE de traitement du code (exploration de classe, refactoring, etc.)
1c) les temps de compilation
2 - la coexistence des chaines destines aux humains (Unicode) et aux API (char *) n'est pas bien gre par la bibliothque standard. On y arrive, mais c'est loin d'tre aussi propre que dans d'autres environnements.

3 - les exceptions ne sont pas accepts dans les projets industriels embarqus, et il faut admettre que c'est pour de bonnes raisons. Il faut vraiment que le standard explore d'autres possibilits. Malheureusement il faut aussi reconnaitre que les solutions industrielles alternatives sont trs loin d'tre unifies.

4 - la mta-programmation trop complexe. Ce sont des bquilles indispensables pour boucher les trous du standard et les retards par rapport aux langages modernes. Mais outre ce que j'ai voqu en 1a, j'ai constat un manque de productivit net pour les programmeurs non-experts lorsqu'ils dcouvrent ces techniques. Je dois me battre sur les check-ins de certains pour interdire la recherche de l'lgance pour l'lgance, qui est parfois bnfique dans la plupart des portions de code mais PAS dans la mta-programmation complexe.


Les faux dfauts pour moi:
1 - le mauvais diagnostic des erreurs de mta programmation. C'est plus rigolo que gnant. Les stagiaires se la ptent  celui qui fera la plus grosse, mais dans la vraie vie ce n'est pas une source perceptible de perte de temps.

2 - les erreurs de pointeurs. a fait des annes que nous n'avons pas eu de retour client sur ce genre de bug. Et pourtant, nous travaillons dans l'embarqu, on est loin d'avoir les Go de matelas des applications PC.

3 - la bibliothque standard rduite ne gne pas dans l'embarqu.

----------


## gl

> A noter que strnlen existe et a pour principale utilit de produire un code sr, comme toutes les fonctions strn*.


Ce n'est pas du C++ standard (ni du C ou Posix) mais une extension GNU.




> Pour moi, c'est a LE gros dfaut de C++ : c'est un langage qui a le cul entre deux chaises. Proche de la machine, mais abstrait quand mme...
> Faut savoir ce qu'on veut. Soit on manipule des concepts, soit on manipule des bits. Mais on mlange pas tout sans arrt, sinon, bonjour la prise de tte.


Et pourtant, cette caractristique du C++ (pouvoir choisir le niveau d'abstraction utilis ou mixer les niveaux d'abstraction) est assez souvent vu plutt comme un avantage que comme un inconvnient.




> Ce sont des bquilles indispensables pour boucher les trous du standard et les retards par rapport aux langages modernes.


A quoi fais-tu allusion ici ?

----------


## davcha

> Et pourtant, cette caractristique du C++ (pouvoir choisir le niveau d'abstraction utilis ou mixer les niveaux d'abstraction) est assez souvent vu plutt comme un avantage que comme un inconvnient.


En temps normal, je dirais que c'est un avantage, en effet. Mais dans le cas prsent... Trop de mauvais devs, srement.

----------


## om

Le plus gnant dans le C++, c'est qu'il soit utilis par les terroristes  ::mouarf::

----------


## Klaim

Je vois aussi cela comme un avantage mais effectivement cot ducation/adoption des dvelopeurs, a aide pas. La plupart des dveloppeurs ont tendance  penser qu'ils agissent quasimment toujours  au niveau sauf si le besoin d'en fait ressentir. Seulement on leur apprend souvent le C with classes qui est encore loin du C++ "moderne". Enfin c'est une discussion qu'on a dj eu dans le coin.

C'est assez difficile de faire comprendre a quelqu'un que ce n'est pas parcequ'une feature de language existe qu'elle est l pour tre utilis de manire systmatique. Du coup expliquer que l'orient objet n'est qu'une petite partie de la solution a un problme est loin d'tre une partie de plaisir.


Il me semble que Stroustrup a dit que son plus grand regret tait qu'il n'y a pas vraiment de communaut centrale autour de C++ et c'est vrai : la connaissance du language est sacrment dilue sur le net, mme si a tend globalement a aller vers le correcte. Je me souviens avoir appris les bases du C with classes sur des tutoriaux sur le net et aujourd'hui je dconseil fortement cette aproche. Les livres sont souvent bien mieux.

Tout a pour dire que le problme d'education est en grande partie responsable de la vision ngative d'avoir un language qui permet d'ecrire du code " tous les niveaux"...
Si on se contente  un moment donn du niveau requis pour le problme immdiat  rsoudre, il n'y a aucun souci avec a. On a mme l'avantage de ne pas avoir a changer de langage.

----------


## alexis b

> Pour moi, c'est a LE gros dfaut de C++ : c'est un langage qui a le cul entre deux chaises. Proche de la machine, mais abstrait quand mme...
> Faut savoir ce qu'on veut. Soit on manipule des concepts, soit on manipule des bits.


Je dirais que c'est un langage un peu schizophrne (mais vous avez votre propre faon de dire les choses ^^).

C'est un langage qui a tous les avantages du C, plus les avantages qui lui sont propres  :;):  . Finalement, que demander de plus ?




> Du coup expliquer que l'orient objet n'est qu'une petite partie de la solution a un problme est loin d'tre une partie de plaisir.


Parce que c'est faux tout simplement, la programmation oriente objet, mme en C++ (qui permet de faire des programmes optimiss), est un lment assez omni-prsent (thoriquement).

----------


## CAMIC

> Le fait qu'on est jamais sr de ce que fait une ligne de code... merci les #define, la surcharge d'oprateur, les transtypages implicites, ...


Selon le crateur du C++, Bjarne Stroustrup, le #define ne devrait servir que pour des options pour le prprocesseur, donc pas de macro mais des inlines.

Avec Visual studio 2005 et plus pas de problme pour voir le code qui est actif et non actif entre des #ifdef, #else et #endif.

----------


## koala01

> JParce que c'est faux tout simplement, la programmation oriente objet, mme en C++ (qui permet de faire des programmes optimiss), est un lment assez omni-prsent (thoriquement).


Tu ne semble pas encore avoir assez manipul la STL ou boost, pour avoir une telle raction.

Dans les deux cas que je cite, on a affaire bien plus souvent  une approche gnrique qu' une approche OO, mme si l'orient objet n'est souvent pas trs loin.

De plus, c'est un argument que l'on a trs difficile  faire passer auprs des javaistes ou des C#istes, mme si l'orient objet prsente de trs srieux avantages, il ne faut pas en oublier les limites.

L'approche purement squentielle, base sur des fonctions libres permet dans bien des cas au dveloppeur d'crire un code moins verbeux mais tout aussi comprhensible.

L'approche gnrique quant  elle permet de crer des hirarchies de classe bien moins complexes et donc...  beaucoup plus flexibles en vitant d'introduire dans une hirarchie des branches entires qui n'auraient sans doute rien  y faire.

Il ne s'agit pas de remettre en cause les bienfaits de l'orient objet, comprenons nous bien, il s'agit simplement de faire prendre conscience que l'orient objet n'est pas forcment la panace pour laquelle on essaye de le faire passer.

De tous temps, il s'est trouv des charlatans pour essayer de nous vendre des remdes prtendant tout soigner, du simple rhume au cancer, en passant par la goutte ou les morpions, et soit-disant totalement exempts d'effets secondaires mais tous en avaient effectivement, et trs peu taient rellement efficaces.

L'orient objet apporte certes un grand nombre de solutions  certains problme, mais, comme tout remde, il faut tre conscient des effets secondaires qu'il entraine.

Les autres paradigmes permettent d'attnuer ces effets secondaires lorsqu'ils sont utiliss  bon escient, et c'est de cela que le C++istes essayent de faire prendre conscience aux autres  :;):

----------

