Discussion :

[niarkyzator]

L'eternelle "Segmentation Fault" est beaucoup plus plus classe que l'immonde pâté du java.null.exeption.

Et la chasse à la seg fault est une vrai bataille de l'homme contre la machine, ça rend le codage en c++ presque épique !

C'est pas vraiment pertinant mais en tant qu'étudiant, je trouve que coder en c++ c'est beaucoup plus fun que coder en Java, on se rend mieux compte de la puissance qu'on a dans les main, on est fier de ses algo. Le java donne un peu l'impression de joueur au duplo, on emboite des grosses briques toutes faites, même si au final le résultat est le même, et qu'on va plus vite en java.

Par contre y'a un truc que j'accepterai jamais de faire, c'est de retourner au pascal et ses immondes := / BEGIN / END

[Alp]

L'eternelle "Segmentation Fault" est beaucoup plus plus classe que l'immonde pâté du java.null.exeption.

Et la chasse à la seg fault est une vrai bataille de l'homme contre la machine, ça rend le codage en c++ presque épique !

C'est pas vraiment pertinant mais en tant qu'étudiant, je trouve que coder en c++ c'est beaucoup plus fun que coder en Java, on se rend mieux compte de la puissance qu'on a dans les main, on est fier de ses algo. Le java donne un peu l'impression de joueur au duplo, on emboite des grosses briques toutes faites, même si au final le résultat est le même, et qu'on va plus vite en java.

Par contre y'a un truc que j'accepterai jamais de faire, c'est de retourner au pascal et ses immondes := / BEGIN / END

Ce que tu dis n'est pas tout à fait juste, cf ce que j'ai dit au-dessus.

[Florian Goo]

Tout à fait d'accord avec Alp.

Si on le désire, on peut faire du aussi haut-niveau que Java en C++. À partir du moment où l'on adopte les bonnes pratiques (ce qu'on appelle pompeusement le C++ moderne), coder en C++ est aussi simple (voire plus) que de coder en Java.
En C++ moderne, on manipule des pointeurs intelligents et on n'a plus à gérer la mémoire manuellement.
La seule « complexité » supplémentaire que je perçois, c'est la différenciation des allocations sur la pile et sur le tas. Mais cette complexité vient avec une contrepartie de poids qu'est l'idiome RAII (expression barbare désignant un mécanisme qui n'a rien de compliqué à intégrer) qui finalement facilite bien des choses.
Le C++ est plus riche en fonctionnalités, et pas seulement en fonctionnalités bas-niveau.

Et puis, saviez-vous qu'il est tout à fait possible d'avoir des fuites mémoires en Java ?

Le C++ n'est pas un « langage d'avant », contrairement à ce que vous appelez « C/C++ ». Une prochaine version du C++ est d'ailleurs en cours d'élaboration.
Et non, nous ne sommes pas « bien sûr en manque d'outils et de bibliothèques », bien au contraire !

Donc pour répondre à la question :
Personnellement j'ai été élevé au Java et j'ai découvert le C++ par moi-même. En fin de compte la question est à inverser dans mon cas : « Souhaiteriez-vous reprogrammer en Java après des années d'utilisation de C++ ? ». Réponse : oh que non, tant qu'on me laissera le choix.

[deadalnix]

Aussi d'accord avec alp.

Déjà, C/C++, ça m'énerve aussi La seule chose qu'il partagent, c'est la syntaxe. Mais le fait est que C++, c'est un langage ou on doit tout faire d'origine.

Oui, on peut faire du comptage de référence ou du GC en C++, mais faut el faire à la main ou utiliser une lib. De base, ça n'y est pas. Maintenant, connaitre le C++, c'est aussi connaitre ces outils. Et s'emmerder à tout faire à la main en C++ de nos jours, c'est simplement ne pas connaitre C++. On à la toute la différence entre connaitre un langage, et puis les usages, la culture, les pratiques, etc . . .

Le principal reproche que je ferait à C++, c'est que malgré qu'il y ai tous les outils dont on a besoin, ils ne sont pas pensés dans un esprit global. Le soucis vient du fait qu'on ai pris le C, puis qu'on y ai ajouté tellement de trucs en plus qu'on obtient finalement un truc qui n'a plus rien à voir. Bref, un impression de langage patché et repatché. On arrive à un moment ou faut la version 2.0 (D ?).

[niarkyzator]

@Alp Je cherchais pas l'exactitude dans mes propos, j'ai bien lu que le C++ permet de la programmation de haut niveau, simplement j'en ai pas encore fait, je me bas toujours avec mes * et mes new.

Par contre j'ai pas l'impression que C et C++ n'aient que leur syntaxe de commune, ça m'est arrivé plusieurs fois de compiler du C avec g++, sans aller jusqu'a dire que le C est completement inclus dans le C++ (j'en sais rien mais ça me parait plausible), y'a quand même un sacré tronc commun.

Par contre Florian, jsuis curieu de savoir comment tu fais pour avoir des pointeurs intelligents.

[smyley]

Par contre Florian, jsuis curieu de savoir comment tu fais pour avoir des pointeurs intelligents.

genre ça http://www.codeproject.com/KB/stl/boostsmartptr.aspx

[Florian Goo]

Voilà .

Et il faut savoir que les pointeurs intelligents de Boost vont (et le sont même déjà partiellement dans le « technical report ») être inclus dans la bibliothèque standard :
- std::shared_ptr
- std::weak_ptr (alter ego des WeakReference de Java)
- std::unique_ptr (pour les ressources non partagées)

Je travaille sur un projet d'environ 15000 lignes. Zéro « delete » !

[_skip]

Et il y a aussi le scoped_ptr je crois qui est très utile, pour moi ce sont parfois des meilleures réponses que les try-finally des langages managés lorsqu'il s'agit de s'assurer de la libération de ressources.

[pseudocode]

Voilà .

Et il faut savoir que les pointeurs intelligents de Boost vont (et le sont même déjà partiellement dans le « technical report ») être inclus dans la bibliothèque standard :
- std::shared_ptr
- std::weak_ptr (alter ego des WeakReference de Java)
- std::unique_ptr (pour les ressources non partagées)

Je travaille sur un projet d'environ 15000 lignes. Zéro « delete » !

Et il y a aussi le scoped_ptr je crois qui est très utile, pour moi ce sont parfois des meilleures réponses que les try-finally des langages managés lorsqu'il s'agit de s'assurer de la libération de ressources.

Hum... Si le but c'est de se créer son propre "sur-langage" au dessus du C++, autant carrément prendre C#, Java ou Vala. non ?

[Florian Goo]

@skip
Oui, on appelle ça le RAII .

Le scoped_ptr de Boost, c'est la solution en attendant le std::unique_ptr du prochain standard du C++.

[Florian Goo]

Hum... Si le but c'est de se créer son propre "sur-langage" au dessus du C++, autant carrément prendre C#, Java ou Vala. non ?

L'avantage c'est que tu peux « débrayer » pour retomber dans le plus bas niveau si besoin (de la même façon que tu débraies un appareil photo en passant du mode automatique à un mode manuel).
Il n'y a pas de problème à partir du moment où les concepts de bas-niveau sont bien encapsulés dans les outils que tu utilises (en l'occurrence les pointeurs intelligents).

Mais pourquoi parler de sur-langage ?
En Java on a bien les WeakReference de l'API standard, qu'il est fortement conseillé d'utiliser pour éviter les fuites mémoire. On est dans le sur-langage dans ce cas, pour toi ?

[_skip]

@skip
Oui, on appelle ça le RAII .

Le scoped_ptr de Boost, c'est la solution en attendant le std::unique_ptr du prochain standard du C++.

Pas exactement, à ce que j'en sais, unique_ptr est moveable, idéal si tu veux par exemple allouer un objet dans une fonction et le retourner en transférant la propriété.
Je crois pas qu'un scoped_ptr est moveable mais je peux me gourrer.

[pseudocode]

L'avantage c'est que tu peux « débrayer » pour retomber dans le plus bas niveau si besoin (de la même façon que tu débraies un appareil photo en passant du mode automatique à un mode manuel).
Il n'y a pas de problème à partir du moment où les concepts de bas-niveau sont bien encapsulés dans les outils que tu utilises (en l'occurrence les pointeurs intelligents).

C'est une question de point de vue, mais je préfère que cette "isolation" entre low et high-level soit effectuée par le langage, et non pas seulement par la bonne conduite du programmeur. En ce sens, je préfère l'approche Java/JNI ou C#/Pinvoke : au moins, je sais quelles parties du code sont "sensibles".

C'est d'ailleurs mon plus grand reproche au C++ : pouvoir faire du C/assembleur, toucher aux pointeurs, faire des cast statiques... tout ca au milieu d'une approche 100% Orienté-Objet... C'est un facteur de risque.

Du coup, quand on appelle une méthode en C++ on n'est jamais certain qu'il n'y aura pas d'effet de bord. La preuve est est le "buffer overflow" sur des chaines de caractères, ce qui ne devrait plus exister depuis longtemps avec l'utilisation de la STL, mais qui existe toujours a cause de l'omniprésence du char*.

La puissance du code dit "hybride" est aussi un grand danger. Et pour une application critique je préfère éviter les technos potentiellement dangereuses, quitte à me passer de cette puissance.

Mais pourquoi parler de sur-langage ?

Bah, quand je vois l'un qui dit qu'il veut faire du C sans pointeurs, et l'autre qui dit qui veut faire du C++ sans delete(), je me dit qu'il faut peut-être s'intéresser a d'autres langages. Vouloir transformer le C++ en langage universel n'est peut-être pas la bonne approche, surtout avec la multitude de langage dédié qui existe aujourd'hui.

[Florian Goo]

Pas exactement, à ce que j'en sais, unique_ptr est moveable, idéal si tu veux par exemple allouer un objet dans une fonction et le retourner en transférant la propriété.
Je crois pas qu'un scoped_ptr est moveable mais je peux me gourrer.

C'est tout à fait ça . C'est pour ça que je parlais de solution en attendant [mieux].

[CedricMocquillon]

C'est dommage que le C++ garde cette image des années pré-2003 et VC6. Perso, des seg fault j'en ai pas vu de puis au moins 4 ans (date à laquelle j'ai appris le fameux C++ "moderne") mais pour ça faut aussi se mettre à jour...

La preuve est est le "buffer overflow" sur des chaines de caractères, ce qui ne devrait plus exister depuis longtemps avec l'utilisation de la STL, mais qui existe toujours a cause de l'omniprésence du char*.

En fait le fait de passer par des char* est généralement utilisé pour l'appel de lib C et dans ce cas je vois pas trop de différenciation avec ta vision Java/JNI ou C#/Pinvoke

[pseudocode]

C'est dommage que le C++ garde cette image des années pré-2003 et VC6. Perso, des seg fault j'en ai pas vu de puis au moins 4 ans (date à laquelle j'ai appris le fameux C++ "moderne") mais pour ça faut aussi se mettre à jour...

On en revient a la "bonne conduite" du programmeur, et non pas à la sécurité du langage.

En fait le fait de passer par des char* est généralement utilisé pour l'appel de lib C et dans ce cas je vois pas trop de différenciation avec ta vision Java/JNI ou C#/Pinvoke

La différence, c'est le nombre d'endroit ou il est possible de faire ce "passage". Dans une application de 200.000 lignes C++, on peut le faire n'importe quand. Dans une application de 200.000 lignes Java/Jni, on ne peut le faire que dans le code natif JNI. Ca fait moins de code a passer en revue, non ?

[CedricMocquillon]

On en revient a la "bonne conduite" du programmeur, et non pas à la sécurité du langage.

Entièrement d'accord avec toi, cependant un programmeur ayant une "mauvaise conduite" peut à mon avis faire autant de dégâts dans d'autres langages. Le problème viens sans doute plus de la formation C++ qui n'est pas toujours à jour (un peu comme si on apprenait des éléments dépréciés des versions antérieures de Java)

La différence, c'est le nombre d'endroit ou il est possible de faire ce "passage". Dans une application de 200.000 lignes C++, on peut le faire n'importe quand. Dans une application de 200.000 lignes Java/Jni, on ne peut le faire que dans le code natif JNI.

Encore une fois entièrement d'accord avec toi, mais c'est également un problème de "bonne conduite" et de non respect de l'encapsulation/découpage du projet. Si le développeur Java décide de faire plein d'appel JNI éparpillés dans son code ce sera pas forcément beaucoup plus maintenable que des appels à des fonctionnalités/pratiques du C dans du code C++.

[Florian Goo]

C'est une question de point de vue, mais je préfère que cette "isolation" entre low et high-level soit effectuée par le langage, et non pas seulement par la bonne conduite du programmeur. En ce sens, je préfère l'approche Java/JNI ou C#/Pinvoke : au moins, je sais quelles parties du code sont "sensibles".

C'est d'ailleurs mon plus grand reproche au C++ : pouvoir faire du C/assembleur, toucher aux pointeurs, faire des cast statiques... tout ca au milieu d'une approche 100% Orienté-Objet... C'est un facteur de risque.

Le multiparadigme a en effet le défaut de ses qualités. « With great power comes great responsibility » !

Du coup, quand on appelle une méthode en C++ on n'est jamais certain qu'il n'y aura pas d'effet de bord. La preuve est est le "buffer overflow" sur des chaines de caractères, ce qui ne devrait plus exister depuis longtemps avec l'utilisation de la STL, mais qui existe toujours a cause de l'omniprésence du char*.

Quand on appelle une fonction, on est jamais certain que cette dernière ne contient pas de bug, quel que soit le langage !

La puissance du code dit "hybride" est aussi un grand danger. Et pour une application critique je préfère éviter les technos potentiellement dangereuses, quitte à me passer de cette puissance.

Je comprends ton point de vue mais ne le partage pas.
Il existe en C++ un ensemble de bonnes pratiques qui ne nécessitent pas plus d'efforts de programmation une fois assimilées. Dès lors qu'on dispose de bons outils et d'une bonne équipe, le danger n'est plus. Faciliter la tâche du développeur au détriment de la qualité finale du programme, à mon sens c'est partir dans la mauvaise direction.

Bah, quand je vois l'un qui dit qu'il veut faire du C sans pointeurs, et l'autre qui dit qui veut faire du C++ sans delete(), je me dit qu'il faut peut-être s'intéresser a d'autres langages. Vouloir transformer le C++ en langage universel n'est peut-être pas la bonne approche, surtout avec la multitude de langage dédié qui existe aujourd'hui.

Comme je le disais, le multiparadigme a le défaut de ses qualités. Mais pouvoir débrayer vers le bas niveau lorsque c'est nécessaire est une fonctionnalité supplémentaire qui peut servir. Un plus grand panel de fonctionnalités est un avantage.

Changer de langage ? Pourquoi pas, ne soyons pas sectaire. Mais à l'heure actuelle, je n'ai pas trouvé de langage plus safe avec lequel je ne me sente pas bridé (quoique je devrais me pencher un peu plus sur les langages fonctionnels tels que le Haskell… quand j'aurai le temps !).

[_skip]

Pour avoir fait pas mal de C++ récemment je trouve tout de même que se gourrer peut vite arriver, l'exemple le plus souvent cité est la non-destruction d'objets pointés, qu'on peut résoudre de façon élégante, Mais il y a aussi la duplication d'objet par copie à laquelle il faut être prudent, par exemple en les ajoutant dans des conteneurs ou en les passant en paramètre.

Des erreurs de programmation objet liés à la duplication ou à la durée de vie, ça peut arriver assez vite, à mon sens plus qu'en java ou en c#. Il est vrai que ça se résoud en grande partie avec de la rigueur mais il y aura toujours le risque du grain de sel infime difficile à déceler qui provient d'un jour ou le programmeur a du faire un truc en urgence alors qu'il n'était pas en forme.

Sinon comme cela a été dit, je ne peux qu'inviter les personnes qui ont une expérience c++ datée d'actualiser leur vision des choses. Perso j'ai redécouvert ce langage grâce à des libs et des toolkits comme boost et Qt, ça n'a rien à voir avec les horreurs que j'ai connu en cours il y a 7-8 ans.

Bref que dire sinon que je souhaiterai voir émerger un langage comme D, qui allie la puissance d'un langage compilé et les avantages du managé.

[pseudocode]

Je comprends ton point de vue mais ne le partage pas. Il existe en C++ un ensemble de bonnes pratiques qui ne nécessitent pas plus d'efforts de programmation une fois assimilées. Dès lors qu'on dispose de bons outils et d'une bonne équipe, le danger n'est plus.

Effectivement, il est toujours possible de réduire les risques par de la formations, des audits, des outils, ... Mais tout cela à un coup (financier, délai). Dans mes jeunes années () j'étais aussi convaincu que l'existence de bonnes pratiques était une garantie suffisante. Avec le temps j'ai appris que les bonnes pratiques sont plus souvent contournées que les limitations du langage.

Faciliter la tâche du développeur au détriment de la qualité finale du programme, à mon sens c'est partir dans la mauvaise direction.

Je ne parle pas du tout de qualité mais de sécurité (au sens "fiabilité" ou "robustesse").

Par exemple, je n'imagine pas un FAI qui permette a ses utilisateurs de coder leurs pages perso en C++ au lieu de PHP. Pas plus que je n'imagine de remplacer les scripts LUA par du C++ dans les jeux. Et ce n'est pas pour des questions de performances ou de qualité, mais juste de sécurité.

Changer de langage ? Pourquoi pas, ne soyons pas sectaire. Mais à l'heure actuelle, je n'ai pas trouvé de langage plus safe avec lequel je ne me sente pas bridé.

Et je ne pense pas que tu le trouveras. La sécurité se paye par la limitation des possibilités offertes.