Discussion :

[Florian Goo]

C'est justement la le problème l'interface existe virtuellement , pour les chaines de caractères il y a autant de types que de libraires techniques.

On est d'accord que le retrait des concepts de C++0x est déplorable, mais ils existent bel et bien et pas seulement virtuellement.
C'est comme si tu disais que les interfaces n'existaient pas en C++ simplement parce que le mot-clé « interface » n'existe pas…

et si t'utilise std::string il y en a d'autres qui utilisent char* ou QString ou CString ou ATL::CString ou autre.

Il me semble qu'on t'a déjà répondu à ce sujet.

char*, c'est du C, dont le C++ hérite.
Si tu te retrouves avec une fonction qui prend un const char*, str.c_str() et roule ma poule.
Une fonction qui renvoie un const char* ? std::string a le constructeur qui va bien.

CString ? Les MFC c'est objectivement de la merde, pourquoi continuer à en parler ? (C'est bien du MFC, non ? J'ai cherché « CString » sur Google pour m'en assurer… hum… ne faites pas ça chez vous, les enfants )

En ce qui concerne les redondances entre Qt et la STL (que je suis le premier à déplorer), il faut savoir que Qt est antérieur à la STL. Et de toute façon, si j'en crois les commentaires de mes confrères, l'interaction entre les deux types n'est pas très douloureuse.

wxWidgets, gtkmm et d'autres ont également leur type string propre. Mais en fait, est-ce vraiment un problème si terrible ?
Lorsque l'on utilise une bibliothèque, il faut autant que possible éviter de rendre le code dépendant de celle-ci, éviter d'être dépendant de ses types, de ses structures de données, etc. Le projet utilise ses structures de données propres en interne dans ses classes métiers (quand rien n'existe dans la STL ou dans Boost) et fait les conversions et wrappings qui vont bien dans le code encapsulant les libs en question (preuve qu'on sait ce que c'est, une abstraction).
En quoi serait-ce une précaution propre au C++ ?

et le vrai intérêt du concept ce n'est pas de l'avoir dans la tête mais concrètement avoir l'entité qui fait l'abstraction pour que la communication entre librairies soit facile.

On attend tous les concept_map avec impatience .

et pour ta critique sur ma phrase:

pour être clair pour concept je parle la de classe abstract pure indépendante de toute implémentation, a tu compter combien il y en a dans STL,Boost et QT ?

par exemple dans QTCore de QT je peux t'assurer qu'il n y a pas assez d'abstraction et essaye d'énumérer combien de classes abstraites pur qu tu rencontre dans les différents projets sur lesquels t'a travailler.

Sans vouloir t'attaquer personnellement (je me suis moi aussi posé ces questions au cour de mon apprentissage du C++, venant à l'origine du Java), cette remarque en dit plus sur ta maitrise du langage que sur les soit-disant faiblesses de ces bibliothèques.
La virtualité des interfaces a un cout au runtime. L'abstraction apportée par les templates déplace ce cout à la compilation.
Pourquoi n'y a-t-il pas d'interface IContainer dans la STL ? Parce que les concepts de conteneurs la remplacent avantageusement.
Tu vas peut-être encore me répondre que ce n'est pas assez concret à ton gout, et pourtant c'est grâce à ça que les algorithmes de la STL fonctionnent (et fonctionnent même extrêmement bien).

d'autre part ne prenais pas comme attaque personel chaque idée evoqué,

Nous débâtons dans le calme et je m'en réjouis . Merci à toi pour cela.

on est entrain de débattre de la manière d'aborder c++ pour convaincre les décideurs que C++ n'est pas si compliqué que ca.

J'ai plus l'impression que ce qui se passe, c'est qu'on est tous en train d'essayer te convaincre que tu mets le doigt sur des faux problèmes (ce qui ne veut pas dire qu'il n'y a pas de vrai problème).

et si t'est convaincu que le monde de C++ c'est le paradis et il n y a aucun souci de complexité de ces librairies (je parle bien de librairies mais non du langage) tu n'a qu'a demander a ton DRH combien maintenant c'est mission impossible de trouver un bon profil C++.

Bien sûr que le C++ peut mieux faire, sinon le comité et ses innombrables débats n'auraient pas lieu d'être.
Bien sûr qu'il y a des bibliothèques qu'on aimerait voir disparaitre. Ici, on pousse les gens à utiliser les bonnes.
Toutefois, je ne pense pas qu'on puisse attribuer cet état de fait (la difficulté de trouver des bons codeurs C++) à tous les « problèmes » que tu as désigné. À mon humble avis, c'est plus un problème d'enseignement.


Enfin, pour DotNet, désolé, je ne connais pas du tout !

[Issam_Lahlali]

On est d'accord que le retrait des concepts de C++0x est déplorable, mais ils existent bel et bien et pas seulement virtuellement.
C'est comme si tu disais que les interfaces n'existaient pas en C++ simplement parce que le mot-clé « interface » n'existe pas…

je pense que la il y a juste un mal entendu je parle de classe abstract pur comme équivalent en c++, mais lorsque je dis que ca n'existe pas je parlais du type chaine de caractère ou peut être même File ou autre classe technique.

et merci pour tes remarques c'est ce que je considère comme constructive même si je l'avoues des fois j'évoque des idées qui peuvent paraitre bizarre ou choquer mais il n y a pas mieux de rester dans le cadre de débat d'idées

[JolyLoic]

par exemple pour la classe abstract pure pour représenter les contrats , un développeur C++ ne la voit bcp dans les librairies qu'ils utilisent, par contre un développeur c# voit régulièrement les interfaces.

Tu as utilisé plusieurs fois cet exemple, en utilisant parfois le terme concept au lieu de contrat.

Déjà, es-tu conscient que le mot concept a un sens particulier en C++, et qu'il a failli devenir un mot clef du langage (et qu'il le deviendra probablement dans le futur) ?

Ensuite, une classe abstraite n'est qu'un moyen parmi d'autres en C++ d'énoncer une interface. Et une interface au sens C# du terme serait considérée comme une très mauvaise façon de faire en C++, puisqu'il n'y a aucune possibilité de valider les pré/post conditions.

Enfin, dans mon code, j'utilise beaucoup des ostream, ainsi que des conteneurs et des itérateurs. Les trois sont des interfaces, réalisées de manières différentes, car résultant de compromis différents.

[Issam_Lahlali]

Tu as utilisé plusieurs fois cet exemple, en utilisant parfois le terme concept au lieu de contrat.

Déjà, es-tu conscient que le mot concept a un sens particulier en C++, et qu'il a failli devenir un mot clef du langage (et qu'il le deviendra probablement dans le futur) ?

par concept c'est l'abstraction et le contrat dont je fais allusion pas le concept qui n'est pas encore malheureusement dans le standard.

et je parle beaucoup d'abstraction et de contrat vu les avantages qu'elles apportent:

- couplage faible surtout si on adopte une architecture par composants.
- très utile lorsqu'on a plusieurs implémentations possibles.
- permet de définir les contrats possible d'un métier donnée, d'où son importance lors de la conception des classes métiers.

[Luc Hermitte]

par exemple pour la classe abstract pure pour représenter les contrats , un développeur C++ ne la voit bcp dans les librairies qu'ils utilisent, par contre un développeur c# voit régulièrement les interfaces.

Les interfaces C#/Java/COM/CORBA sont à mille lieux de ce qu'est un contrat à la Eiffel.
En Java il y aura des préprocesseurs externes, et en C++ juste lui et un peu d'huile de coude/bon Environnement de Développement pour mettre en oeuvre le pattern NVI.

De plus ces interfaces introduiraient quantités de problèmes en C++ qui permet la définition de classes valeurs -- cf l'incompatibilité technique entre la sémantique de valeur et les hiérarchies polymorphes.
Et de toutes façons, ce n'est pas leur existence qui changerait quoique ce soit aux volontés discordantes de tel ou tel autre fournisseur de bibliothèque/API/framework. La preuve, ils continuent à offrir leur propre type chaine, voire même un type fichier...
Les shims de Matthew Wilson sont une solution à ce problème si vraiment il vous pourrit la vie dans ta boite.

Et oui il n'y a pas un seul héritage dans la STL. A.Stepanov en parle dans ses Notes On Programming si mes souvenirs sont bons. Son cours d'algorithmique, publié, mais malheureusement plus en ligne est également des plus intéressants.

[Issam_Lahlali]

merci pour vos reponses , et en les prenants en compte voici une vision un peu modifié de mon point de vue de depart:

- C++ est devenu trop complexe et expert friendly d'après l'opinion même de son créateur.

- les planning de développements dans les boites sont serrés.

- trouver des développeurs C++ n'est plus chose facile, donc on fait avec 3 développeurs au lieu de 4 par exemple même si la boite a les moyens pour embaucher le 4eme mais elle ne le trouve pas facilement=> manque de ressources.

- pour un projet on donne la priorité aux risques.

on combinant tout ces facteurs on passe plus de temps a coder pour un langage comme c++ qu'a concevoir dans un milieu d'entreprise, ce qui amène a une implémentation compliqué et donne l'impression que C++ n'est plus un langage productif.

et le décideur veut finalement passer a java ou c#, rien que le fait de ne pas trouver des profils c++ maintenant incite les décideurs a choisir une techno ou ils trouveront des ressources, ils laisseront que ce qui ne peuvent pas migrer dans d'autres langages cad programmation système,jeux,embarqué

Et pour rectifier le point de vue qui a causer pas mal de critique , il n y a pas absence de bon concepteurs c++ mais la loi du marché et l'environnement ambiant fait qu'on a pas le temps de concevoir en entreprise, c'est vrai pour les autres langages mais ça se voit plus pour c++ pour les raisons évoquées auparavant.

Et ce point de vue ne concerne pas ceux qui ont des patrons anciens développeurs et qui leur donne le temps pour concevoir parce qu'ils comprennent l'intérêt.

et si c'est possible d'organiser un sondage sur ce site pour connaitre le temps passé a la conception pour les projets C++ ça sera intéressant.

et si on a comme résultat qu'on passe en général le temps qu'il faut en entreprise pour concevoir les applications C++, je retirais tout ce que j'ai dis depuis le départ

[loufoque]

Pour clarification, C++0x n'apportera que des chaînes littérales UTF-16 et UTF-32, pas UTF-8.
De plus, elles seront fort probablement assez inutiles de manière portable puisque les compilateurs vont effectuer des conversions depuis le source character set vers UTF-16 ou UTF-32, et comme le source character set c'est l'encodage local dans les implémentations [1] (c'est-à-dire ANSI pour les compilos Windows, UTF-8 pour la plupart des installations Linux), ça va veut qu'on devra se limiter à ASCII pour utiliser ces chaînes littérales.
Ça ne change pas grand chose par rapport à wchar_t, sauf que là l'encodage sera spécifié, ce qui n'apporte rien en pratique, puisqu'on peut déjà se baser sur le fait que c'est soit UTF-16 soit UTF-32.

Une bonne solution à ce problème, ce serait si Windows permettait d'utiliser UTF-8 comme locale, mais c'est pas près d'arriver...

L'Unicode, et même dans une certaine mesure les chaînes de caractères, c'est pas terrible en C++, mais c'est pas forcément vraiment mieux dans les autres langages.

[1] MSVC peut travailler avec un source character set en UTF-8 BOM ou UTF-16, mais non seulement cela empêche la compatibilité avec les autres compilateurs, ça signifie aussi que les littéraux char seront convertis en ANSI.

[ymoreau]

Et oui il n'y a pas un seul héritage dans la STL.

Ah bon?? Pourtant selon ce site.. :
Pourtant : http://www.cplusplus.com/reference/iostream/ostream/
"The class (ostream) inherits all the internal fields from its parent classes ios_base and ios"

..la classe ostream hérite, et je pensais d'ailleurs que les {i|o}[f]stream avait tous les mêmes ancêtres. J'ai faux ?

[JolyLoic]

..la classe ostream hérite, et je pensais d'ailleurs que les {i|o}[f]stream avait tous les mêmes ancêtres. J'ai faux ?

Les iostreams font partie de la SL, mais pas de la sous partie de celle-ci qu'on nomme STL.

[teddyalbina]

Pour clarification, C++0x n'apportera que des chaînes littérales UTF-16 et UTF-32, pas UTF-8.
De plus, elles seront fort probablement assez inutiles de manière portable puisque les compilateurs vont effectuer des conversions depuis le source character set vers UTF-16 ou UTF-32, et comme le source character set c'est l'encodage local dans les implémentations [1] (c'est-à-dire ANSI pour les compilos Windows, UTF-8 pour la plupart des installations Linux), ça va veut qu'on devra se limiter à ASCII pour utiliser ces chaînes littérales.
Ça ne change pas grand chose par rapport à wchar_t, sauf que là l'encodage sera spécifié, ce qui n'apporte rien en pratique, puisqu'on peut déjà se baser sur le fait que c'est soit UTF-16 soit UTF-32.

Une bonne solution à ce problème, ce serait si Windows permettait d'utiliser UTF-8 comme locale, mais c'est pas près d'arriver...

L'Unicode, et même dans une certaine mesure les chaînes de caractères, c'est pas terrible en C++, mais c'est pas forcément vraiment mieux dans les autres langages.

[1] MSVC peut travailler avec un source character set en UTF-8 BOM ou UTF-16, mais non seulement cela empêche la compatibilité avec les autres compilateurs, ça signifie aussi que les littéraux char seront convertis en ANSI.

En fait windows utilise UTF-16LE il me semble que sous Nt 6.x c'est utf-8 faut aussi si je me souviens bien faire gaffe à ta fonction Main parce que si je ne dis pas de conneries

main(..) // le compilo se dit ok le gars a tout fait en ANSI
Main(..) // Viva unicode

[Jean-Marc.Bourguet]

Pour clarification, C++0x n'apportera que des chaînes littérales UTF-16 et UTF-32, pas UTF-8.

A string literal that begins with u8, such as u8"asdf", is a UTF-8 string literal and is initialized with the given characters as encoded in UTF-8.

[Issam_Lahlali]

Les interfaces C#/Java/COM/CORBA sont à mille lieux de ce qu'est un contrat à la Eiffel.
En Java il y aura des préprocesseurs externes, et en C++ juste lui et un peu d'huile de coude/bon Environnement de Développement pour mettre en oeuvre le pattern NVI.

pour revenir a l'idée de passer par interface et son intérêt dans un monde ou on a énormément d'implémentations.

imaginant qu'on a une classe abstract pure IFile qui contient les methodes :open,close,write,read,...

et dans mon code C++ j'ai

IFile *f= new ConcreteFile(); au lieu de ConcreteFile *f= new ConcreteFile()

alors je serais découpler de l'implémentation et je peux changer de librairies pour les files sans se poser de question si je trouve que la première libraire a des problèmes.

et si pour toutes les classes techniques on a une abstraction aussi ca sera a mon avis très bénéfiques.

d'ailleurs rien ne m'empêche de faire moi même une librairie AbstractLib qui contient l'abstraction de la majorité de classes techniques utilisées

et après faire des wrappers pour l'adapter a différentes librairies, comme ca un developpeur C++ n'a a apprendre qu'une seule librairie AbstractLib et en plus si je me rends compte que je me suis gouré dans le choix de la librairie , le switch vers une autre librairie sera très rapide.

bien sur je parle d'un monde idéale mais s'il ya des efforts dans ce sens je crois qu'on simplifiera plus l'utilisation des librairies.

[hegros]

Normal qu'on s'intéresse plus à la technique en C++ c'est intrinsèquement lié au langage. Exemple : tu surcharges l'opérateur = de classes avec attributs dynamiques alors il faudra définir ton constructeur par recopie : ce qui est au départ est une belle conception(surcharge des opérateurs) se traduit par du technique pour éviter des plantages mémoires..


la conception technique du langage impose de passer du temps sur la programmation technique avec tout ses pièges et erreurs.


Je dirais aussi que la communauté C++ s'intéresse plus à la technique car c'est un langage plus bas niveau et que bien que cela ne plaira pas à certains mais il garde ses faiblesses du C ou là aussi on s'intéresse plus à la technique qu'à la conception (mais comme il faut bien que ce genre de langage existe aussi ce n'est pas vraiment un problème)

[saad.hessane]

Bonjour,
Je voulais juste rebondir sur le fait que la discussion n'est pas du tout stérile et loin d'être un troll. En essayant de vous convaincre l'un l'autre vous fournissez tous des arguments très instructifs pour la joie et le bonheur des débutants comme moi.
Je pense que c'est surtout la faute à l'enseignement si C++ parait comme étant un langage d'"élite". Quand on étudie du JAVA ou du C#, on fait un petit peu de langage pour vite passer au design pattern. En C++ on reste plutôt focaliser sur l'aspect technique comme tu le dis, vu qu'il y a plein plein plein de nouvelles choses à voir qu'il n'est pas simple de pratiquer.
Il y a aussi l'effet de mode, qui fait que les écoles négliges vraiment le C++ au profit des nouvelles technologies. Le cursus des élèves est maintenant constitué de java, technologie .NET, J2EE, technologie WEB ...

[koala01]

Bonjour,
Je voulais juste rebondir sur le fait que la discussion n'est pas du tout stérile et loin d'être un troll. En essayant de vous convaincre l'un l'autre vous fournissez tous des arguments très instructifs pour la joie et le bonheur des débutants comme moi.
Je pense que c'est surtout la faute à l'enseignement si C++ parait comme étant un langage d'"élite". Quand on étudie du JAVA ou du C#, on fait un petit peu de langage pour vite passer au design pattern. En C++ on reste plutôt focaliser sur l'aspect technique comme tu le dis, vu qu'il y a plein plein plein de nouvelles choses à voir qu'il n'est pas simple de pratiquer.
Il y a aussi l'effet de mode, qui fait que les écoles négliges vraiment le C++ au profit des nouvelles technologies. Le cursus des élèves est maintenant constitué de java, technologie .NET, J2EE, technologie WEB ...

Le tout, sans oublier la foule de prof (pas forcément incompétents) qui apprennent un odieux mélange de C et de C++ en présentant ceci comme le C++...

[Luc Hermitte]

pour revenir a l'idée de passer par interface et son intérêt dans un monde ou on a énormément d'implémentations.

imaginant qu'on a une classe abstract pure IFile qui contient les methodes :open,close,write,read,...

et dans mon code C++ j'ai

IFile *f= new ConcreteFile(); au lieu de ConcreteFile *f= new ConcreteFile(

Pour moi, sur un tel aspect technique, cela n'a pas d'intérêt. On va se retrouver à donner le plus petit sous-ensemble commun à cette interface, LSP oblige, et donc perdre l'intérêt (à supposer qu'il y en ait un) d'utiliser un type autre que le standard. Et on devra continuer à jongler avec des bibliothèques qui pour d'obscures raisons continuent à proposer une alternative aux flux standards -- pour pouvoir profiter des services supplémentaire. Pas besoin de complexifier plus la situation.

Les interfaces à la Java sont une fausse bonne idée. Elles sous-exploitent les possibilités du langage, sans parler qu'un point de variabilité dynamique ne présente aucune intérêt sur une fonction qui va attendre une chaine ou un fichier.

PS: Tu n'as pas googlé avec le mot-clé que je t'avais donné dans mon précédent message, n'est-pas ?

[hegros]

Le tout, sans oublier la foule de prof (pas forcément incompétents) qui apprennent un odieux mélange de C et de C++ en présentant ceci comme le C++...

c'est du à la conception du langage en lui même cela lui est intrinsèque. Quand tu as un fichier .cpp c'est du C++ que tu compiles qui dira le contraire ?

Le fait est que tu peux compiler en C++ du code C...Le C++ traîne avec lui le C...Le fait qu'on puisse autant mélanger montre bien le lien fort qui existe entre ces 2 langages.

Facile de rejeter la faute sur les profs avec autant de contrainte contradictoire sur ce langage.

[loufoque]

Désolé pour les chaînes littérales UTF-8, apparemment elles ont été rajoutées après.

[Jean-Marc.Bourguet]

Facile de rejeter la faute sur les profs avec autant de contrainte contradictoire sur ce langage.

C'est vrai, si les profs ne sont pas a jour sur la matiere qu'ils enseignent, c'est la faute a la matiere.

J'aimerais bien voir un prof en medecine essayer cette attitude.

Oui, le C++ est un langage complexe; personne ne le lie. Prendre pretexte de cette complexite pour excuser ceux qui n'enseignent pas les moyens de la maitriser, ca me semble assez ubuesque.

[Invité]

Le tout, sans oublier la foule de prof (pas forcément incompétents) qui apprennent un odieux mélange de C et de C++ en présentant ceci comme le C++...

Mais peut être que c'est une bonne chose... Sans cet "odieux mélange", le C++ serait il utilisé, autrement que marginalement, en entreprise? (l'aurait on jamais utilisé?) Et s'il n'était pas utilisé, aurions nous ces belles bibliothèques, ces beaux compilateurs, tous ces bons livres de référence ?

Je pense qu'il faut arrêter de ne voir dans le C++ que le langage du futur qu'il promet d'être depuis bientôt 10 ans. A mon avis, c'est tout autant du Not Invented Here que vouloir récrire sa STL maison.

Francois