[debat] Le mot clef const

Citation:

---

Envoyé par Dr Dédé

- la conversion de caractères (<locale> )

---

Je peux que le féliciter. Ce bout de code est un truc infâme.

Citation:

---

Envoyé par Dr Dédé

- les strings (<string>)

---

o_O pourquoi ? optimiser la concatenation ? si oui, ostringstream quoi

Citation:

---

Envoyé par Dr Dédé

- l'allocateur par défaut

---

C'est fait pour.


Faut garder à l'esprit que C++ c'ets un langage opt in. Y a un strict minimum, tu construit le reste (ou tu utilises du déja construit).
Apres, pour conclure sur ce fil qui ne va nul part, j'ai envie de te dire que si ça te perturbe tant, change de boulot et va faire autre chose :aie:

Citation:

---

Envoyé par Dr Dédé

Complétion de code, refactorings, aides visuelles, aides à la sélection, à la copie, etc. Regarde par exemple ce que Coderush peut faire: http://www.devexpress.com/Products/V...ance/index.xml

---

A part pour le refactoring, tu trouve qu'il n'y as pas d'équivalent en C++???
Après j'ai peut être pas besoin des même outils que toi. Mais bon ce n'est pas le sujet du thread.

Citation:

---

Je dois ne pas comprendre quelque chose dans ton exemple, car si ta classe propose une interface listener, alors le listener qui s'y connecte n'a accès qu'aux méthodes de l'interface listener. Donc, le listener ne peut pas faire n'importe quoi, et si ta classe ne se modifie pas elle-même dans son implémentation de l'interface, alors le listener ne peut pas la modifier. Il pourrait toujours faire un cast dans le type dérivé, mais peut aussi faire un const_cast en C++.

---

Je parle de la donné que tu transmet. Le listener qui la reçois peut la manipuler et si on fait pas attention, il pourrais la modifier et impacter le fonctionnement.
C'est un exemple mais y as beaucoup de cas que je trouve potentiellement dangereux.

Citation:

---

Certainement. Mais dans bien des langages, il faut des besoins plus spécialisés que "je dois afficher quelque chose à l'écran" pour avoir à sortir de la librairie standard. Et donc, le problème existe ailleurs, mais dans une moindre mesure.

---

Marrant, personnellement, quand je compte les langages qui viennent avec une interface graphique dans leur librairie standard, je m'arrête assez vite. Allons y : java, java, hum smalltalk, et allez soyons généreux D. go / python / ruby / perl / php / js / erlang / haskell / ocaml / scheme / common lisp ... utilisent des librairies externes, et des bindings C/C++.

Quand tu regarde un environnement intégré comme gnome, tu trouve du C, du C++, du C#, du js, du python, du ruby, et j'en oublie certainement. Pas uniquement du C et C++. Le C et le C++ sont là pour batir les fondations (c'est un peu comme le CLR de .Net, mais en natif). Neaucoup de choses de haut niveau sont réalisés dans des langages de plus haut-niveau. Je connais aussi un certain nombre de jeux, sans forcément beaucoup de prétention, batis sur python / SDL.

Quand à la portabilité, la jvm ou mono est aussi rempli de #ifdef #endif (mince c'est écrit dans des langages bas-niveau en plus). Qt et/ou Boost ont fait ce travail pour toi, et propose des interfaces portables (ou Poco, ACE, ...). Du point de vue des développeurs utilisateurs de ces librairies, quelle est la différence ?

Pas compris ta réponse sur WPF, je répondais juste aux inexactitudes de tes propos : 1/ WPF c'est génial mais ce n'est pas portable 2/ l'utilisation de Qt ne t'oblige pas à releaser ton code ton GPL 3/ qu'est que fait WPF de si merveilleux ?

tout est dit

c'est dommage d'avoir fait chavirer la convesation dans du C# est mieux que C++. La question originale etait "C++ avec const est il mieux que C++ sans const". Avoir amené C# et Java parce qu'ils compilent plus vite, ca a juste fait dégénerer le thread.
Dr Dédé obtient donc +10 points Troll.

Mais si toutes les variables etaient const par defaut et que, pour pouvoir les changer, il fallait utiliser un mot cle (mutable par exemple), le code source ne serait-il pas un peu lourd?
D'ailleurs, le mot "variable" dit bien qu'il s'agit de quelque-chose qui, par defaut, peut changer.

Citation:

---

Envoyé par el_socio

Mais si toutes les variables etaient const par defaut et que, pour pouvoir les changer, il fallait utiliser un mot cle (mutable par exemple), le code source ne serait-il pas un peu lourd?
D'ailleurs, le mot "variable" dit bien qu'il s'agit de quelque-chose qui, par defaut, peut changer.

---

On parlerait alors simplement de constantes ;)

Il existe d'ailleurs des langages dans lesquels on manipule des objets exclusivement constants, et où une modification passe d'office par... la création d'un nouvel objet :P

Citation:

---

Envoyé par koala01

Il existe d'ailleurs des langages dans lesquels on manipule des objets exclusivement constants, et où une modification passe d'office par... la création d'un nouvel objet :P

---

Oui mais ce sont des langages fonctionnels, qui ont une "philosophie" tres differente du c++.
Je ne sais pas, j'ai du mal a m'imaginer le c++ avec les variables constantes par defaut, mais j'ai l'impression que ca n'est pas tres compatible. La plupart des arguments que je passe a mes fonctions ne sont et ne doivent pas etre constant. Enfin je sais pas, j'ai l'impression.
Mais c'est une idee interessante. C'est d'ailleurs pour ca que j'essaie de participer, meme si ca me depasse un peu, et que je ne sais pas trop qu'est-ce que je peux apporter a la discussion :oops:

On peut toujours apporter a une discussion :)
Le truc, c'est que je pense que beaucoup plus de choses sont constantes que les gens ne le pensent. Bien sûr a la fin il faut bien écrire quelque chose a l'écran, mais au final peu de données sont réellement changées

ensuite, c'est surtout pour l'encapsulation que je pense a ca, pas pour les variables locales ou les paramètres.
Je pense que la plupart des méthodes d'un objet pourraient être const et ca peut être un oubli de ne pas le mettre. Cela peut aussi forcer les gens a faire du code "const" là ou une solution avec du code "mutable" fonctionnerait aussi, ca changerait un peu la facon dont les gens pensent. Mais ca je ne sais pas si c'est une bonne ou une mauvaise chose

Citation:

---

Envoyé par zul

Pas compris ta réponse sur WPF, je répondais juste aux inexactitudes de tes propos : 1/ WPF c'est génial mais ce n'est pas portable 2/ l'utilisation de Qt ne t'oblige pas à releaser ton code ton GPL 3/ qu'est que fait WPF de si merveilleux ?

---

WPF, ben il a apporté une énorme facilité dans la conception d'IHM très jolies, souples, graphismes vectoriels et accélérées graphiquement en plus, pour des clients desktop quoi.

Son XAML, même s'il n'est pas parfait partout, avec son système de bindings de propriétés, c'était quand même quelque chose de radicalement facile à utiliser.

La réponse de Qt ?
QML, Qt Quick, tout ça. Je n'ai pas testé, ça a l'air bien mais en tout cas c'est portable !

Quand ça fait longtemps qu'on a pas touché à du C++, se remettre à du Qt pur et dur ça fait un peu mal, alors qu'avec WPF c'était quand même plus lubrifié.

Citation:

---

Envoyé par el_socio

Je ne sais pas, j'ai du mal a m'imaginer le c++ avec les variables constantes par defaut, mais j'ai l'impression que ca n'est pas tres compatible.

---

C'est surtout que le langae n'applique pas la constance par défaut...

Autrement, tu aurais sans doute du mal à imaginer le langage appliquant la non constance par défaut :D

Citation:

---

La plupart des arguments que je passe a mes fonctions ne sont et ne doivent pas etre constant. Enfin je sais pas, j'ai l'impression.

---

A vrai dire, la plupart des arguments que je passe à mes fonctions sont, au contraire, constants et doivent l'être :P

Qt supporte lui aussi l'accélération hardware, en particulier dans l'embarqué (google te donnera un certains nombre de références sur le sujet). Quand à savoir si WPF/C# est pluis intuitif que C++/Qt, c'est à mon avis une question trop subjective. J'aurai aimé entendre ses arguments sur WPF, vu que c'est une solution en tout point supérieur ...

+1 pour l'immutabilité par défaut (même si on ne le verra jamais en C++).

Citation:

---

Envoyé par zul

+1 pour l'immutabilité par défaut (même si on ne le verra jamais en C++).

---

Trop de lignes de code seraient à jeter si on devait changer un tel point.

Citation:

---

Envoyé par Davidbrcz

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.

---

Pour l'extract method sous Vim, il me reste à me motiver pour faire une petite IHM où spécifier comment on veut échanger nos variables retour simple/tuple, paramètre pointeur/référence, via une struct/classe, ...
Et moi et les IHM ...

Mais le gros problème est effectivement l'absence d'outils simples, ouverts (au sens non couplés à un autre EDI), et capables de remonter des infos pertinentes et suffisantes. Parce que ctags ... mais quelle galère!


Pour les temps de compils, effectivement le langage demande du boulot manuel : réfléchir (je sais c'est dur...) aux dépendances inter-modules/fichiers, utiliser des déclarations anticipées, sortir les en-têtes précompilés.
On peut également profiter de certains outils comme gnu-make qui disposent d'une option -j fort appréciable sur les machines multi-coeurs/procs.

Citation:

---

Envoyé par Luc Hermitte

On peut également profiter de certains outils comme gnu-make qui disposent d'une option -j fort appréciable sur les machines multi-coeurs/procs.

---

Pour info, Visual Studio a également cette possibilité avec /MP comme paramètre dans la ligne de commande. ;)

Bonjour,

l'éternel débat sur l'infâme mot-clé const :mrgreen:
Moi je trouve ça bien ce type de discussion, ça fait réfléchir et ça fait vivre le langage.

J'en profite pour placer une petite question, concernant les lambdas du c++0x:
Prenons le code suivant:

Code:

---

1 2 3 4 5 6 7

vector<int> v; // code to put something into the vector   for_each( v.begin(), v.end(), [val] (int n) { n++; // c'est cette ligne qui est importante // do something });

---

dans ce code, si j'ai bien compris, ce que fait la ligne n++ c'est... rien ^^!
C'est rien parce que n est const à l'interieur du scope (ici le scope c'est le troisieme parametre du for_each).
Mais ce qui est bizarre c'est que ça compile! (sur vs2010. Je n'ai pas testé avec gcc).
C'est prévu dans la norme ça?

Enfin je sais pas, je vous parle de ça parce que ça me parait dangereux.

Non, n n'est pas const (il n'y a pas de const écrit, donc il n'est pas const).

En revanche, c'est une valeur qui est la copie de ce qui a été fourni en paramettre : changer sa valeur sans utiliser le resultat ne fait...rien.
Le code reste valide (d'où la compilation), mais ne sert a rien.

Si c'était une référence, ça aurait certainemetn plus t'interet.

Enfin, si c'était const, ça ne compilerai tout simplement pas puisque ++ require un accès en écriture (et const est comme une limitation à l lecture).

Ha oui effectivement. Bien vu :ccool:
Je crois que je vais adopter rapidement ces lambdas, parce que j'aime bien utiliser des foncteurs mais mon code devient vite illisible à force de mettre des foncteurs partout. Mais là je suis plus que hors-sujet, pardon :oops:

Oui c'est un peu hors sujet mais je viens de commencer a les utiliser et je me rends compte que ça simplifie a mort l'encapsulation!

Par exemple si tu as un TrucManager et que tu veux appliquer un algo à tous les Trucs managés, alors il suffit de faire une fonction qui fait un foreach avec un fonctor et de lui passer une lambda avec ta fonction.

Plus besoin d'exposer des itérateurs à tous le coups ou d'exposer directement des conteneurs!

*Touss touss* ahem, fin du hors sujet.

@R0d, ne voulais-tu pas montrer c'est que la capture par valeur qui est constante :

Code:

---

1 2 3 4

int n(0); auto lambda = [n](){++n;}; // ERREUR // ou : auto lambda2 = [=](){++n;}; // ERREUR

---

Il faut que ce soit mutable :

Code:

---

1 2 3 4

int n(0); auto lambda = [n]()mutable {++n;}; // OK // ou : auto lambda2 = [=]()mutable{++n;};// OK

---

Ce qui est un peu perturbant car la capture par référence est non constante elle :

Code:

---

1 2 3 4

int n(0); auto lambda = [&n](){++n;};// OK // ou : auto lambda2 = [&](){++n;}; // OK

---

et qu'il n'y a pas moyen de faire une capture par référence constante :aie: sauf de façon alambiquée :

Code:

---

1 2 3 4 5

int n(0); int const &rn = n; auto lambda = [&rn](){++rn;}; // Erreur liée au type de rn et pas à la capture par référence // ou : auto lambda2 = [&](){++rn;}; // Erreur liée au type de rn et pas à la capture par référence

---

Mais bon, la capture d'un contexte n'est pas le passage d'un argument.

Sinon : les lambdas, c'est 1000% :ccool: