[debat] Le mot clef const

Citation:

---

Si tu crée deux fonctions l’une « const » et l’autre « non-const » et à cette dernière tu lui affuble
le mot clé « mutable », ce qui n’a aucun sens étant donné que par défaut toute zone mémoire est « mutable » !

---

ça a tout a fait un sens au contraire, un objet déclarer const ou non const, une fonction pouvant être appeler dans un objet const et non const utilisant une variable membre de cette objet...
mutable est un mot clé qui n'a de signification que pour la classe elle-même, à l'intérieur d'elle! Un contrat c'est entre l'utilisateur et la classe, ce n'est pas entre la classe et... la même classe.

Citation:

---

Envoyé par Flob90

@Chessmaster1966: Tu expliques ce que fait mutable, gl t'as donné sa raison d'être : indiquer que certaines variable ne participes pas à l'état "publique" d'un objet : ie que leur modification n'influe pas sur la vision qu'un utilisateur extérieur aura de l'objet. Ce qui signifie qu'en pratique une variable mutable d'un objet const pourra quand même être modifié car const ne fait qu'indiquer que l'objet est immuable pour les utilisateurs. Ce qui implique que mutable ne rompt aucun contrat.

---

Effectivement dans la réponse à gl je me suis un petit peu emporté. Je suis d'accord dans ce contexte il n'ya pas rupture de contrat parce qu'il n'y a pas de contrat :mouarf:.

Que pour modifier les données membres d'un objet "const" il faut les déclarer "mutable".

On est d'accord !!!

Je n'ai pas le temps de répondre en détail à tous ceux qui m'ont répondu depuis la dernière fois, mais j'ai pensé à un truc ce matin. C++ est le seul langage que je connaisse où il existe ce concept de "const-correctness" et je m'y suis toujours opposé comme étant un ennui parmi d'autres de ce langage. Néanmoins, je peux comprendre comment la solution qui prévaut ailleurs (types immuables, encapsulation par accesseurs virtuels, etc.) n'est pas forcément satisfaisante en C++. En effet, difficile de travailler avec des types immuables dans un environnement non géré, et le coût des fonctions virtuelles est loin d'être nul (principalement parce qu'une méthode virtuelle ne peut pas être inline). Cette solution ne serait donc pas applicable dans les domaines de prédilection du C++, soit les systèmes embarqués, temps réel, haute performance (jeux vidéos), systèmes d'exploitation, etc, parce que dans ces contextes chaque cycle cpu compte: pas question que chaque accès à une donnée entraîne un appel de fonction virtuelle ou la création d'un nouvel objet.

const a donc l'avantage de ne rien coûter à l'exécution. Et là où la performance n'est pas si importante, on ferait mieux d'utiliser autre chose que C++. De ce point de vue, const a donc sa place dans le langage.

Citation:

---

Envoyé par yan

D’ailleurs es ce que quelqu'un sait pourquoi Java (et C#?) n'ont pas ajouté un équivalent à const?

---

Dieu soit loué... :lol:

Plus sérieusement, l'absence de const en Java est un des plus fameux "bugs": http://bugs.sun.com/bugdatabase/view...bug_id=4211070

Fermé depuis 2005, je crois, avec l'explication suivante:

Citation:

---

There are no current plans to add this feature to Java. In
addition to creeping featurism, we see the following problems
with this feature:

* Adding const is too late now. Had this been added from 1.0,
the situation could have been different.

* Const pollution: the C++ approach requires all const methods
to be marked with a const keyword. This means that most
methods will have to be marked const explicitly. This tend
to clutter all methods in C++.

* Compatibility is a very important feature of the JDK.
Arguably, the collection classes should be modified to
indicate that the elements are const. That would
require all existing implementations to be updated in
the same way, effectively breaking all existing non-JDK
implementations of the collection interfaces. Similarly,
hashCode would have to be const, breaking the current
implementation of String.

---

En d'autres termes: 1) C'est un ajout sans valeur 2) Il est trop tard 3) Const est une pollution, il se propage partout 4) Cela briserait les conteneurs standards existants (similaire à 1))

En C#, Anders Hejlsberg a déjà répondu à cette question:
http://www.artima.com/intv/choicesP.html

Citation:

---

Anders Hejlsberg: Yes. With respect to const, it's interesting, because we hear that complaint all the time too: "Why don't you have const?" Implicit in the question is, "Why don't you have const that is enforced by the runtime?" That's really what people are asking, although they don't come out and say it that way.

The reason that const works in C++ is because you can cast it away. If you couldn't cast it away, then your world would suck. If you declare a method that takes a const Bla, you could pass it a non-const Bla. But if it's the other way around you can't. If you declare a method that takes a non-const Bla, you can't pass it a const Bla. So now you're stuck. So you gradually need a const version of everything that isn't const, and you end up with a shadow world. In C++ you get away with it, because as with anything in C++ it is purely optional whether you want this check or not. You can just whack the constness away if you don't like it.

---

En résumé: 1) const ne fonctionne en C++ que parce qu'on peut le contourner (const_cast); 2) const conduit à avoir des versions const de tout ce qui n'est pas const, créant ainsi une duplication (ce qui n'est pas si problématique en C++ à cause de 1)).

Citation:

---

Envoyé par Dr Dédé

Je n'ai pas le temps de répondre en détail à tous ceux qui m'ont répondu depuis la dernière fois, mais j'ai pensé à un truc ce matin. C++ est le seul langage que je connaisse où il existe ce concept de "const-correctness" et je m'y suis toujours opposé comme étant un ennui parmi d'autres de ce langage. Néanmoins, je peux comprendre comment la solution qui prévaut ailleurs (types immuables, encapsulation par accesseurs virtuels, etc.) n'est pas forcément satisfaisante en C++. En effet, difficile de travailler avec des types immuables dans un environnement non géré, et le coût des fonctions virtuelles est loin d'être nul (principalement parce qu'une méthode virtuelle ne peut pas être inline). Cette solution ne serait donc pas applicable dans les domaines de prédilection du C++, soit les systèmes embarqués, temps réel, haute performance (jeux vidéos), systèmes d'exploitation, etc, parce que dans ces contextes chaque cycle cpu compte: pas question que chaque accès à une donnée entraîne un appel de fonction virtuelle ou la création d'un nouvel objet.

---

Oui, c'est une des raisons...

Une autre étant, comme je l'ai expliqué plus haut, que le principe d'interface est sympa, mais qu'il ne faut pas non plus en abuser, du moins, lorsque le langage permet de s'en passer.

Je vais garder pour moi mon opinion sur les langages qui institutionnalisent le recours aux interfaces parce que c'est largement hors sujet (et qu'il y a déjà des débats sur les qualités et les défauts comparés de ces langages entre eux ou par rapport à C++ :D), mais il faut avouer qu'une interface n'étant jamais qu'une classe (ou une structure) en C++, leur généralisation nous fait assister à une véritable explosion au niveau du nombre de classes que l'on a à gérer, et qu'une telle explosion est forcément contre productive.

Elle n'apporte rien en terme de sécurité en C++ et, malgré tout, apporte une complexification globale du projet qui, se répercutera, fatalement, sur les coups de développement et de maintenance.

Et nous sommes bien d'accord sur le fait que je ne dis pas qu'il ne faut pas utiliser les interfaces, mais que je dis qu'il faut les utiliser... à bon escient ;)

Citation:

---

const a donc l'avantage de ne rien coûter à l'exécution. Et là où la performance n'est pas si importante, on ferait mieux d'utiliser autre chose que C++.

---

Heeuuu... oui, mais non...

Oui, dans le sens où il faut reconnaitre que C++ est un langage complexe, difficile à maitriser, et qu'il est donc "facile" de trouver des langages dans lesquels les gens seront plus rapidement productifs.

Non, parce que... "qui peut le plus peut le moins".

Si tu as affaire à quelqu'un de compétant en développement et à un codeur qui maitrise le langage, il ne sera pas plus lent à fournir un résultat que quelqu'un ayant choisi un autre langage.

Et comme les performances seront généralement meilleures que ce que tu souhaites, tu n'aurais pas beaucoup de raisons de te plaindre :D

Mais bon, les égouts et les couleuvres en terme de langage préféré, cela ne se discute pas ;)

Citation:

---

De ce point de vue, const a donc sa place dans le langage.

---

Enfin...

Il ne reste plus qu'à te convaincre de l'utilité des références, pour se dire que l'on n'a pas perdu notre temps avec toi, et pour pouvoir espérer que tes développement futurs en C++ gagnent en qualité (je ne juge pas ici de la qualité de tes développement passés pour la cause, hein :question:) :D

Citation:

---

Envoyé par Dr Dédé

En C#, Anders Hejlsberg a déjà répondu à cette question:
http://www.artima.com/intv/choicesP.html
En résumé: 1) const ne fonctionne en C++ que parce qu'on peut le contourner (const_cast); 2) const conduit à avoir des versions const de tout ce qui n'est pas const, créant ainsi une duplication (ce qui n'est pas si problématique en C++ à cause de 1)).

---

Mr Heilsberg est peut être une pointure en C#, mais je me permet d'émettre quelque doutes quant à sa compétence en C++ "moderne" :aie:

Si j'admets qu'il est parfois utile de dupliquer une fonction déclarée constante dans une version non constante, c'est loin d'être le cas général.

C'est, effectivement, utile lorsque tu veux renvoyer des itérateurs sur des collections, et encore, il m'arrive régulièrement de n'exposer que des fonctions (constantes) permettant de récupérer des itérateurs... constant, simplement parce qu'il n'y a aucun sens à permettre d'en obtenir d'autres :P

De même, le const-cast est, certes utile, mais son usage est particulièrement loin d'être généralisé.

A titre personnel, je suis par exemple loin de l'utiliser une fois en moyenne par unité de compilation: si je l'utilise une fois sur vingt ou sur cinquante unités de compilation, ca doit déjà faire beaucoup :P

Maintenant, je suis peut être une exception sur ces points, mais j'en serais assez surpris ;)

Au sujet de const, je crois que tout a été dit. On ne ferait que répéter ce qu'on a déjà dit à continuer cette discussion.

Citation:

---

Si tu as affaire à quelqu'un de compétant en développement et à un codeur qui maitrise le langage, il ne sera pas plus lent à fournir un résultat que quelqu'un ayant choisi un autre langage.

---

Quand même bien on ferait abstraction des maigres librairies standards, de la gestion de mémoire, de la gestion des fichiers d'en-tête, des messages d'erreurs cryptiques, de l'absence de refactorings efficaces, admettons que notre programmeur C++ arrive à compenser tous ces inconvénients sans perte de temps aucune (c'est un dieu! 8O), il ne peut pas contourner le fait que la vitesse de compilation du C++ est comparable à celle d'une limace constipée. :P

Citation:

---

Envoyé par koala01

Mr Heilsberg est peut être une pointure en C#, mais je me permet d'émettre quelque doutes quant à sa compétence en C++ "moderne" :aie:

---

Anders Hejlsberg est le concepteur du langage C#. De plus, il est le concepteur de Turbo Pascal, des langages Delphi et J++, et il est un des principaux architectes de la plateforme .NET. :mrgreen:

Citation:

---

Envoyé par Dr Dédé

il ne peut pas contourner le fait que la vitesse de compilation du C++ est comparable à celle d'une limace constipée. :P

---

Ceci dit, les projets aux quels j'ai été confrontés et pour lesquels la vitesse de compilation était problématique était souvent des projets à l'architecture bancale (pour ne pas dire plus) amenant à des dépendances entre les différents modules qui n'auraient pas du être. Bref, un beau plat de spaghetti. Rien à voir avec le langage ;) Pour voir actuellement des collègues transpirer sur du C#, je ne suis pas persuadé que l'assertion 'pour de l'embarqué/critique faite du C++, sinon utiliser un autre langage' soit très pertinente. La difficulté des projets tient (à mon avis) d'abord à la difficulté à saisir le besoin et à la complexité des systèmes mis en œuvre. Le langage n'a qu'une faible part et ses caractéristiques comme la const-correctness sont plus une aide ;) qu'un poids mort (comme le dit screetch plus haut, en substance, le langage, s'il est compris, est plus une aide alors que si on se bat avec cela devient un boulet).

il y a autant de points de vue que de personnes, d'ailleurs moi si je pouvais je virerai le mot clé const, je ne garderais que le mot clé mutable, et tout serait const par defaut. C'est un peu comme ca que j'envisage le langage idéal, parce que ma philosophie c'est "tout ce qui n'est pas explicitement autorisé est interdit", et c'est le compilateur qui l'interdit (si je peux). Mais bon, comme dit koala, les coups et les douleurs hein...

Je souhaite revenir sur quelque points.

Citation:

---

Quand même bien on ferait abstraction des maigres librairies standards,

---

Le standard fournit ce qu'il y a d'essentiel (conteneurs, algorithmes, flux) pour tout programmeur. Le reste(GUI, réseau, what ever else) est loin d'être essentiel et je suis bien content que ca soit hors du standard.

Je préfère amplement cette situation à Java où il y'a une librairie standard énorme avec 10 framework externe pour faire une chose.

Citation:

---

de la gestion de mémoire

---

Tu lui repproches quoi ? Qu'il n'y ait pas de garbage collector ?
Y'avait eu un débat dessus et l'opinion qui en ressortait était "Pourquoi pas, tant qu'on ne me l'impose pas". Personnellement, j'y suis opposé, j'aime bien avoir une gestion déterminée de ma mémoire.

Citation:

---

de la gestion des fichiers d'en-tête

---

Le système des includes peut paraître archaïque mais permet de différencier interface/implémentation très facilement et d'avoir ainsi une vue d'ensemble en quelques secondes. Et cela n'induit pas de temps de compilation excessif si on n'inclut pas tout comme un sagouin mais qu'on utilise des déclarations antincipées.

Je préfère amplement ce système à celui de C# où tout est dans un fichier et qu'on plie/déplie une classe à l'aide de l'éditeur.

Citation:

---

des messages d'erreurs cryptiques

---

Si ca vient de la STL, stlfilt est ton ami. Pour boost, j'ai jamais eu de message de 4km de long mais je veux bien admettre que ca puisse arriver.

Citation:

---

, de l'absence de refactorings efficaces,

---

Ca va dépendre des outils que tu utilises. De mémoire, Visual offrait des outils pas dégeulasse là dessus (certes payant mais bon). Et je ne serait pas surpris que Emacs ou Vim en propose aussi des assez bons.

Citation:

---

admettons que notre programmeur C++ arrive à compenser tous ces inconvénients sans perte de temps aucune (c'est un dieu! 8O),

---

Ouais, on sait qu'être efficace en C++ n'est pas à la porté du premier débutant venu alors qu'un débutant pourra être beaucoup plus rapidement efficace en C# ou en Java.

Mais après, le C++ c'est génial (à 2/3 défauts près :aie:).

Citation:

---

il ne peut pas contourner le fait que la vitesse de compilation du C++ est comparable à celle d'une limace constipée.

---

Un bon compilo avec une machine qui n'est pas un dinosaure, une architecture pas bancale (cela comprend ne pas inclure tout et n'importe quoi) t'assure des temps de compilation raisonnable.

Dr Dédé >> En ce qui concerne ton habitude d'utiliser des pointeurs bruts, tu perds de l'information (et de la sécurité) face à une référence. Est ce que mon pointeur est un tableau C-like ? En suis je responsable (comprendre, est ce que je dois le détruire à la fin de ma fonction) ? Si oui, comment, delete[] ou delete ? Je passe outre la nullité qui a déjà été discutée mais je rajoute la possibilité d'imbriquer les appels ce que les pointeurs complexifie.

screetch >> Teste un langage fonctionnel pur :D

Citation:

---

Envoyé par Davidbrcz

screetch >> Teste un langage fonctionnel pur :D

---

j'y pense parfois :)

Pour le temps de compilation, il est vrai que l'utilisation systématiques des déclarations dans les .h, et les include dans les .cpp sont un bon début.
Personnellement, sous gcc avec l'option -j 4, je gagne un facteur 2.5 encore en compilation.

Sinon, je crois aussi que LLVM apportera un temps de compil beaucoup plus faible dans le futur !

Citation:

---

Pour le temps de compilation, il est vrai que l'utilisation systématiques des déclarations dans les .h, et les include dans les .cpp sont un bon début.
Personnellement, sous gcc avec l'option -j 4, je gagne un facteur 2.5 encore en compilation.

---

Tiens d'ailleurs, un question me taraude. Sous Visual on peut compiler avec l'option /MT ou /MD ( multithread liaison dynamique ou statique).
C'est possible avec d'autres compilateur sous Linux ou OsX?

Citation:

---

Envoyé par Davidbrcz

Le standard fournit ce qu'il y a d'essentiel (conteneurs, algorithmes, flux) pour tout programmeur. Le reste(GUI, réseau, what ever else) est loin d'être essentiel et je suis bien content que ca soit hors du standard.

Je préfère amplement cette situation à Java où il y'a une librairie standard énorme avec 10 framework externe pour faire une chose.

---

+1 surtout si c'est pour avoir un design bancal...

Citation:

---

Envoyé par Davidbrcz

Si ca vient de la STL, stlfilt est ton ami. Pour boost, j'ai jamais eu de message de 4km de long mais je veux bien admettre que ca puisse arriver.

---

Ou apprendre à les lires... (mais je dois avouer que pour le débutant c'est chiatique)


Ouais, on sait qu'être efficace en C++ n'est pas à la porté du premier débutant venu alors qu'un débutant pourra être beaucoup plus rapidement efficace en C# ou en Java#.

Citation:

---

Envoyé par Davidbrcz

Un bon compilo avec une machine qui n'est pas un dinosaure, une architecture pas bancale (cela comprend ne pas inclure tout et n'importe quoi) t'assure des temps de compilation raisonnable.

---

Tant que tu fais pas trop de TMP un peu lourde ..

Mais bon sinon, ça devrait encourager les gens à passer sur clang... :)
Et les entêtes précompilé ça marche bien, je suis déçu que ça se démocratise pas plus..

Citation:

---

Envoyé par Davidbrcz

Je souhaite revenir sur quelque points.
Le standard fournit ce qu'il y a d'essentiel (conteneurs, algorithmes, flux) pour tout programmeur. Le reste(GUI, réseau, what ever else) est loin d'être essentiel et je suis bien content que ca soit hors du standard.

---

Et pourtant, c'est tellement pratique... Non seulement pour le développeur, mais aussi pour celui qui télécharge ton code source et qui a à se taper d'installer toutes les dépendances externes, dans les bonnes versions. En général, si tu vas chercher un projet open-source écrit en Java, C#, Python, etc., tu peux le compiler et le faire s'exécuter de la façon la plus évidente possible, tout de suite. Par exemple, ouvrir la solution et faire "Build". Ou dans le cas de Python, ne rien faire du tout et simplement exécuter le programme. On ne peut pas en dire autant de la plupart des projets C++. Je crois avoir passé 5 bonnes heures avant de réussir à faire compiler un certain remake de Settlers 2, ou Battle for Wesnoth.

Citation:

---

Tu lui repproches quoi ? Qu'il n'y ait pas de garbage collector ?
Y'avait eu un débat dessus et l'opinion qui en ressortait était "Pourquoi pas, tant qu'on ne me l'impose pas". Personnellement, j'y suis opposé, j'aime bien avoir une gestion déterminée de ma mémoire.

---

Il est plus rapide de ne pas avoir à gérer qqchose que d'avoir à le gérer. La question n'est pas "j'aime ou non", mais bien "est-ce que pour les besoins de mon programme, je peux me passer de gérer cet aspect, ou est-ce nécessaire de le gérer manuellement?". Or, dans un vaste éventail de situations, la réponse sera "un garbage collector ferait aussi bien sinon mieux que moi", et dans cette optique, quand bien même je "préfèrere" la gestion manuelle, je perds mon temps à l'implémenter. À noter qu'il est possible d'avoir un garbage collector en C++, mais c'est du travail à mettre en place.

Citation:

---

Le système des includes peut paraître archaïque mais permet de différencier interface/implémentation très facilement et d'avoir ainsi une vue d'ensemble en quelques secondes. Et cela n'induit pas de temps de compilation excessif si on n'inclut pas tout comme un sagouin mais qu'on utilise des déclarations antincipées.

Je préfère amplement ce système à celui de C# où tout est dans un fichier et qu'on plie/déplie une classe à l'aide de l'éditeur.

---

Les includes existent pour supporter le modèle de compilation du C et non pour fournir des vues d'ensembles. De toute manière, si vous faites des templates, vous devez savoir que l'implémentation se retrouve nécessairement dans le .h, et on revient au "système de C#", avec le problème évident que tout ce code sera recompilé encore et encore.

Si vous voulez un résumé de votre classe en C#, utilisez la vue "Object Browser" de Visual Studio, c'est bien mieux qu'un fichier d'en-tête.

Citation:

---

Ca va dépendre des outils que tu utilises. De mémoire, Visual offrait des outils pas dégeulasse là dessus (certes payant mais bon). Et je ne serait pas surpris que Emacs ou Vim en propose aussi des assez bons.

---

Mais dans les faits, la qualité et la fiabilité des outils C++ sont inférieurs, parce que C++ est trop complexe (particulièrement à cause du préprocesseur). Resharper n'a rien à envier à Visual AssistX.

Citation:

---

Un bon compilo avec une machine qui n'est pas un dinosaure, une architecture pas bancale (cela comprend ne pas inclure tout et n'importe quoi) t'assure des temps de compilation raisonnable.

---

Raisonnables... pour du C++. Dans des langages interprétés, le temps de compilation est 0, ou à peu près. En Java et C#, il est facilement 10 fois moindre. Tiens, pour illustrer mon point, j'ai compilé les deux plus gros projets C++ et C# sur mon ordinateur actuellement, avec Visual Studio 2008.

L'IDE Sharpdevelop: environ 25MB de code source C#. Temps de compilation: 1 minute 25 secondes.
Le jeu Battle for Wesnoth: environ 6MB de code source C++. Temps de compilation: environ 18 minutes (j'ai arrondi vers le bas).

Donc, environ un quart de l'équivalent C# compile en 12 fois plus de temps (et je suis généreux). On parle donc d'un facteur 50 environ. Bien sûr, ce n'est pas un test très scientifique, mais cela correspond bien à mon expérience en général. Et c'est un fait reconnu avec une explication tout aussi connue. Voir par exemple http://stackoverflow.com/questions/3...n-take-so-long

Les coûts sur le développement sont bien réels. Quand un programmeur te dit "je m'en vais prendre un café en attendant que mon code compile", tu peux tout de suite savoir qu'il travaille en C++.

Citation:

---

Dr Dédé >> En ce qui concerne ton habitude d'utiliser des pointeurs bruts, tu perds de l'information (et de la sécurité) face à une référence. Est ce que mon pointeur est un tableau C-like ? En suis je responsable (comprendre, est ce que je dois le détruire à la fin de ma fonction) ? Si oui, comment, delete[] ou delete ? Je passe outre la nullité qui a déjà été discutée mais je rajoute la possibilité d'imbriquer les appels ce que les pointeurs complexifie.

---

Mais... tu es responsable de libérer la mémoire avec delete ou delete[] que tu utilises des références ou pas. Et comme je m'en tiens à RAII, c'est-à-dire que j'alloue dans des constructeurs et je libère dans les destructeurs correspondants, le fait d'utiliser des pointeurs au lieu de références ne me complique en rien la gestion de mémoire. Pour ce qui est de l'ambiguïté tableau/pointeur, elle ne se pose pour ainsi dire jamais puisque je n'utilise à peu près jamais des tableaux C (il y a std::array maintenant), et dans les rares cas où j'en ai besoin, ils sont membres d'une classe, ou locaux à une fonction, qui sait très bien à quoi elle a affaire à l'interne. Je ne comprends pas ce que tu veux dire pas "imbriquer des appels", en quoi cela se rapporte aux pointeurs?

Encore une fois, t'as le droit d'utiliser les outils adequat. les PCH c'est pas pour les lévriers afghans tout comme savoir comment écrire du code sans dépendance farfelues.

Donc, avant de couiner sur le langage, couine plutot sur les gus qui savent pas coder proprement.

Citation:

---

Envoyé par Joel F

Encore une fois, t'as le droit d'utiliser les outils adequat. les PCH c'est pas pour les lévriers afghans tout comme savoir comment écrire du code sans dépendance farfelues.

Donc, avant de couiner sur le langage, couine plutot sur les gus qui savent pas coder proprement.

---

Certes. Mais il faut reconnaitre que le temps de compilation de C++ est naturellement assez important.

Citation:

---

Envoyé par Dr Dédé

Et pourtant, c'est tellement pratique... Non seulement pour le développeur, mais aussi pour celui qui télécharge ton code source et qui a à se taper d'installer toutes les dépendances externes, dans les bonnes versions. En général, si tu vas chercher un projet open-source écrit en Java, C#, Python, etc., tu peux le compiler et le faire s'exécuter de la façon la plus évidente possible, tout de suite. Par exemple, ouvrir la solution et faire "Build". Ou dans le cas de Python, ne rien faire du tout et simplement exécuter le programme.

---

Visiblement, on ne doit pas utiliser les mêmes programmes. En Python, il m'arrive assez régulièrement de devoir installer une extension ou une autre (PIL par exemple).
Pour le Java, je ne pratique pas assez pour avoir un avis personnel. Mais au dire de mes collègues travaillant avec, je ne suis pas certain que la situation ne soit aussi merveilleuse que ça.

Citation:

---

Envoyé par Dr Dédé

Les includes existent pour supporter le modèle de compilation du C et non pour fournir des vues d'ensembles. De toute manière, si vous faites des templates, vous devez savoir que l'implémentation se retrouve nécessairement dans le .h, et on revient au "système de C#", avec le problème évident que tout ce code sera recompilé encore et encore.

---

Le système des includes n'est certes pas parfait, loin de là. Et effectivement template et inline s'intègre mal dans ce modèle. Mais je suis loin d'être certain que la solution utilisée par de nombreux autres langages qui consiste à ne rien séparer soit réellement meilleure.

Et au passage, comme le fait remarquer Joel, il faut penser aux entêtes précompilées.

Citation:

---

Envoyé par gl

Certes. Mais il faut reconnaitre que le temps de compilation de C++ est naturellement assez important.

---

C'ets au vendeur de compilo de régler ça. Moi en tant que dev., je m'applique juste à pas ecrire du caca.

Citation:

---

Et pourtant, c'est tellement pratique... Non seulement pour le développeur, mais aussi pour celui qui télécharge ton code source et qui a à se taper d'installer toutes les dépendances externes, dans les bonnes versions. En général, si tu vas chercher un projet open-source écrit en Java, C#, Python, etc., tu peux le compiler et le faire s'exécuter de la façon la plus évidente possible, tout de suite. Par exemple, ouvrir la solution et faire "Build". Ou dans le cas de Python, ne rien faire du tout et simplement exécuter le programme. On ne peut pas en dire autant de la plupart des projets C++. Je crois avoir passé 5 bonnes heures avant de réussir à faire compiler un certain remake de Settlers 2, ou Battle for Wesnoth.

---

Je connais plusieurs personnes qui bossent dans des domaines très divers (jeux vidéos, embarqué critique, calcul numérique haute performance) et qui utilisent tous le C++. Tous ont des besoins différents avec des contraintes différentes, je vois mal comment le standard pourrait tous les combler sans que ca devienne un gros foutoir ou qu'ils soient obligés d'aller voir ailleurs pour récupérer un outils que le langage n'offrirait pas. Etant donné que les outils offerts par Java/C#/... sembler contenter tout le monde, est ce que ca ne veut pas dire qu'ils ne sont destinés qu'à un seul type (au sens large) de projet ? Je ne prendrais pas les paris car j'ai peur de la réponse.

De plus, le problème des dépendances est un problème liés aux outils. Sur ma debian, si je télécharge un paquet source d'un logiciel depuis les dépots, j'ai toutes les dépendances que je n'ai pas déjà (car oui, j'ai déjà pas mal de dépendances "classiques" déjà présentes) qui s'installent toute seule. Si je le télécharge depuis le net, les dépendances sont souvent listés et ca me prends 5 mins à installer.

Je n'y peut rien si tu utilises un système où il faut tout aller chercher par soi même sur le net.

Citation:

---

Il est plus rapide de ne pas avoir à gérer qqchose que d'avoir à le gérer. La question n'est pas "j'aime ou non", mais bien "est-ce que pour les besoins de mon programme, je peux me passer de gérer cet aspect, ou est-ce nécessaire de le gérer manuellement?". Or, dans un vaste éventail de situations, la réponse sera "un garbage collector ferait aussi bien sinon mieux que moi", et dans cette optique, quand bien même je "préfèrere" la gestion manuelle, je perds mon temps à l'implémenter. À noter qu'il est possible d'avoir un garbage collector en C++, mais c'est du travail à mettre en place.

---

Je sais pas comment tu codes mais je ne gère (presque) rien manuellement de la mémoire, des classes RAII-ssante offrant tout ce dont j'ai besoin. Je ne vois pas comment un GC pourrait m'offrir quelque chose puisque je ne fais rien de particulier pour gérer ma mémoire.

Citation:

---

Les includes existent pour supporter le modèle de compilation du C et non pour fournir des vues d'ensembles. De toute manière, si vous faites des templates, vous devez savoir que l'implémentation se retrouve nécessairement dans le .h, et on revient au "système de C#", avec le problème évident que tout ce code sera recompilé encore et encore.

---

Les headers sont certes là pour le modèle de compilation, il n'empèche qu'il offre une vue d'ensemble du projet. Et sinon, oui j'utilise les template mais principalement sous forme de template-métaprogramming qui au final n'amène pas du tout au même problème de lisibilité. Il est rare que je doive développer une classe "utilitaire" template.

Citation:

---

Si vous voulez un résumé de votre classe en C#, utilisez la vue "Object Browser" de Visual Studio, c'est bien mieux qu'un fichier d'en-tête.

---

On a les fichiers d'en tête pour ca plus tous les outils externes qui peuvent exister à coté.

Citation:

---

Mais dans les faits, la qualité et la fiabilité des outils C++ sont inférieurs, parce que C++ est trop complexe (particulièrement à cause du préprocesseur). Resharper n'a rien à envier à Visual AssistX.

---

Accordé, les outils de refactoring C++ sont moins puissants que ceux de Java ou C#. Mais à coté, il faut voir que le C++ offre bien plus de liberté que Java ou C# ou n'importe quoi d'autre

Citation:

---

L'IDE Sharpdevelop: environ 25MB de code source C#. Temps de compilation: 1 minute 25 secondes.
Le jeu Battle for Wesnoth: environ 6MB de code source C++. Temps de compilation: environ 18 minutes (j'ai arrondi vers le bas)

Donc, environ un quart de l'équivalent C# compile en 12 fois plus de temps (et je suis généreux). On parle donc d'un facteur 50 environ. Bien sûr, ce n'est pas un test très scientifique, mais cela correspond bien à mon expérience en général. Et c'est un fait reconnu avec une explication tout aussi connue. Voir par exemple http://stackoverflow.com/questions/3...n-take-so-long

---

Tu as toi même donné la réponse. Une compilation C++ fait beaucoup plus de chose qu'une construction en Java/C#. Normal que ca prenne plus de temps. Faudrait comparer ce qui est comparable. Et joel marque un point avec les headers précompilés. Et clang/llvm devrait aussi réduire les temps de compilation.

Citation:

---

Pour ce qui est de l'ambiguïté tableau/pointeur, elle ne se pose pour ainsi dire jamais puisque je n'utilise à peu près jamais des tableaux C (il y a std::array maintenant)

---

Tous les exemples que tu as fournis sont bourrés de pointeurs dans les paramètres des fonctions, comment tu sais si ce sont des tableau ou des objets dans ce cas sans te référer aux commentaires ?

Citation:

---

Je ne comprends pas ce que tu veux dire pas "imbriquer des appels", en quoi cela se rapporte aux pointeurs?

---

Code:

---

foo(bar()).

---

Si foo prend un pointeur, ca oblige bar a renvoyer un pointeur. Pour éviter les fuites de mémoire, un pointeur intelligent c'est mieux et comme y'a pas de conversion automatique de boost::shared_ptr<T> vers T*, tu te retrouves à utiliser get().

Les headers précompilés n'ont pas que des avantages, ça nous empêche notamment d'utiliser les optimisations au moment du linkage je pense à l'option /GL de visual