et tu mets un printf et ta fonction poure devient impure et les perfs chutent et tu comprends pas pourquoi.
le mot clé const n'est pas une lourdeur, c'est une garantie, le mot clé pure devrait etre pris exactement de la meme facon.
Version imprimable
et tu mets un printf et ta fonction poure devient impure et les perfs chutent et tu comprends pas pourquoi.
le mot clé const n'est pas une lourdeur, c'est une garantie, le mot clé pure devrait etre pris exactement de la meme facon.
Le mot clef const est juste une erreur de conception du C++ selon moi.
Cela est déductible dans la chaine de compilation, et ça cause des soucis au dev (il y a qu'a voir les gags comme le move constructor).
Il devrait en être de même pour la virtualité, ou la puretée. À la limite, pourquoi ne pas ajouter un mot clef qui permet de le spécifier explicitement, et qui nous envoie dans les choux si on ne respecte pas ce qu'on a spécifié explicitement, mais que cela ai besoin d'être explicité pour que ce soit le cas est une erreur selon moi.
En D, le compilo est en charge de déduire si les méthodes sont virtuelles ou non (sauf si elle sont explicitement décrite comme final), il se débrouille tout seul pour les CTFE, et ainsi de suite.
Je ne comprend pas pourquoi il ne serait aps en charge de la « purification ». Quitte à pouvoir le spécifier explicitement (par exemple, pour éviter le coup du printf, ou qu'on redéfinisse une fonction virtuelle pure avec une non pure).
Je ne sais que dire…
Il faudrait déjà que tu comprennes l'utilité du mot-clé const, ce qui ne semble pas être le cas (sans vouloir être condescendant). Comme screetch et moi-même te l'expliquons, il ne s'agit pas d'une lourdeur qu'on souhaite déléguer au compilateur, mais d'une garantie, d'un contrat, que l'on est très heureux de pouvoir imposer explicitement.
Sa permet entre autre d'avoir deux versions d'un même fonction ou l'une est plus optimisé. Par exemple dans Qt dû à son implémentation basé sur Copy-On-WriteCitation:
Envoyé par Florian Goo
etCode:
2
3
4
5
6
7
La version sans const est moins rapide, car elle oblige de vérifier et de faire un copie si le buffer est partagé. Car il est impossible de savoir si ce buffer sera accédé en écriture à partir du pointeur qu'il retourne.Code:
2
3
4
Alors que la version avec const impose que l'accès au buffer doit être uniquement en lecture et que la copie n'est donc pas nécessaire.
8OCitation:
Cela est déductible dans la chaine de compilation, et ça cause des soucis au dev (il y a qu'a voir les gags comme le move constructor).
Parceque le compilateur sait mieu que moi les variables qui ne doivent pas être modifiés a l'execution?
J'en doute fortement.
const c'est avant tout une histoire d'accès, d'où le "contrat" qu'on passe en l'utilisant. Or un accès, c'est une histoire de dévelopeurs, pas de compilateur.
Si on allait par là, alors autant laisser le compilateur deviner ce qui est publique, privé ou protégé.
Je comprend bien, mais de mon point de vue ça pose plus de problème de part la lourdeur syntaxique que par la garantie apportée par le const. La programmation par contrat apporte quand même des outils nettement plus élégants et bien plus pratiques à l'usage.Citation:
Envoyé par Florian Goo
La, on n'est pas dans le cas du contrat mais bien dans l'optimisation. D fournis le moyen de définir des méthodes différentes en lecture et écriture sur des données, ce qui permet de répondre différemment au même problème. La solution proposée par D est bien plus légère pour le développeur à l'usage.Citation:
Envoyé par yan
Le mot const fournis des moyens d'optimiser pas mal de choses au niveau du multithreading. Mais C++ n'en tire pas partit pour l'instant.
Le C++ ne peut pas vraiment en tirer partie pour l'optimisation puisque le const n'est pas transitif. Il n'apporte pas de garantie suffisantes concernant l'aliasing de pointeur, c'est pourquoi C99 a apporté restrict.Citation:
Envoyé par deadalnix
Le const C++ sert surtout au programmeur, c'est une convention, alors que le const/immutable dans D2 sera plus lourd mais plus directement exploitable par le compilo, avec plus de static checks.
Sinon pour revenir sur le mot-clef pure, j'ai vu des compilateurs C++ l'utiliser, sans checking cependant:
#pragma pure
int myFunction(int a)
{
// implémentation
}
Le couple compilo/linker savait ensuite tenir compte du fait que la fonction n'a pas d'effet de bord.
D2 officialise pure et nothrow qui existent déjà dans C++ comme des extensions (GCC par exemple).
Il est, à mon sens, bien plus logique de faire en sorte que la règle de base moins de restriction que les règles particulières, et de faire en sorte que les restrictions doivent explicitement citées que l'inverse qui consisterait à faire en sorte que la règle de base présente déjà un maximum de restrictions qui nécessitent d'être explicitement "désactivée".Citation:
Envoyé par deadalnix
Prenons le cas de java, par exemple:
La règle générale qui concerne le passage d'argument est qu'ils sont passés sous forme de référence constante.
Si le fait qu'il soient, simplement, passés par référence peut être un avantage (en évitant la copie), si l'idée est de modifier l'argument, il faut passer par trois étapes:là où il aurait été possible de n'avoir qu'une étape (qui aurait été la modification de l'argument) si l'argument n'avait été passé que sous la forme d'une référence (non constante).
- création d'un objet "modifié"
- assignation de l'objet modifié à l'argument
- destruction de l'objet d'origine
Le fait de passer d'office un argument sous la forme d'une référence (considérée ici comme non constante) pose des problèmes analogues:
Nous évitons, bien sur, la copie de l'objet passé en argument, mais, en retour, si nous le modifions, l'argument, nous modifions également l'objet d'origine, et, pour éviter ce fait il faudrait de toutes manières... effectuer une copie de l'argument.
La solution avancée par C# de donner systématiquement une sémnatique de valeur au structures et une sémantique d'objet aux classes n'est, en définitive, pas forcément concluante non plus:
Il n'y a, a priori, aucune raison qui nous interdise de considérer un type particulier de donnée tantot comme ayant sémantique de valeur et tantot comme ayant sémantique d'objet selon le contexte dans lequel le type est utilisé (le contexte étant, normalement, donné par... la fonction qui utilise le type en question).
Oui, à condition d'effectuer une étude complète et récursive de la fonction...Citation:
Cela est déductible dans la chaine de compilation, et ça cause des soucis au dev (il y a qu'a voir les gags comme le move constructor).
Si j'utilise le terme complet, c'est parce qu'il faut s'assurer qu'aucune instruction apparaissant dans la fonction ne modifie l'objet au départ duquel la fonction est invoquée.
Si j'utilise le terme récursif, c'est parce qu'il faut, en plus, s'assurer qu'aucune des fonctions que nous pourrions invoquer au départ de l'objet à l'intérieur d'une fonction donnée ne modifiera effectivement le dit objet...
Bref, c'est effectivement faisable, mais au prix d'efforts , et partant, d'un temps de compilation, bien plus importants que ce que l'on peut observer en demandant simplement d'exprimer explicitement le fait qu'une fonction s'engage à ne pas modifier un objet.
De plus, il ne faut pas sous-estimer l'aspect "auto-documenté" de la chose : la (re)lecture et la compréhension d'un code indiquant explicitement qu'une fonction s'engage à ne pas modifier un objet est grandement facilitée, et susceptible de donner des indications intéressantes au lecteur ;)
Parce que ni la virtualité ni la pureté d'une fonction ne sont forcément le meilleur des choix pour la "règle générale".Citation:
Il devrait en être de même pour la virtualité, ou la puretée. À la limite, pourquoi ne pas ajouter un mot clef qui permet de le spécifier explicitement, et qui nous envoie dans les choux si on ne respecte pas ce qu'on a spécifié explicitement, mais que cela ai besoin d'être explicité pour que ce soit le cas est une erreur selon moi.
Bien sur, la virtualité devient indispensable en cas de polymorphisme, mais le polymorphisme n'est pas forcément la qualité la plus remarquable recherchée en programmation objet...
Ce point de vue peut, effectivement, se défendre, mais, à mon sens (encore une fois), il a tendance à traiter le problème à l'envers:Citation:
En D, le compilo est en charge de déduire si les méthodes sont virtuelles ou non (sauf si elle sont explicitement décrite comme final), il se débrouille tout seul pour les CTFE, et ainsi de suite.
Il met en évidence le fait que l'on considère le polymoprhisme comme la qualité primordiale recherchée par la programmation orientée objet, alors que ce n'est, à mon sens du moins, pas le cas.
Je vois bien l'intérêt d'expliciter qu'un fonction est pure. Je ne vois pas l'intérêt qu'on doive expliciter le fait qu'un fonction est pure pour que le compilo le sache.
Ce n'est pas aussi compliqué que ce que tu laisses penser dans ton message car tu prend le problème à l'envers. Il faut que tu fasse ton graphe dans l'autre sens, cad non pas de la fonction qui appele vers la fonction appelée mais dans l'autre sens.
En effet, dans l'autre sens l'algorithme à utiliser est le même que celui d'un GC. Sauf que la ou avec un GC on a des zones mémoire à libérer, la on a les fonction pures.
Ces algos sont connus, maitrisés, et largement assez rapide.
Le compilo doit tagger les fonction : pure, impure ou « pure sous réserve que les fonctions appelées soient pures » que je vais appelées « pures sous réserve » pour faire court. Le linker doit exécuter un algo similaire à celui des GC.
Les fonction impures sont ce qu'on appelle les roots pointer dans un GC. Les fonctions pures sous réserves sont les bloc mémoires allouées. On ignore les fonctions pures.
On parcours le graphe et on taggue impur tout ce qui nous tombe sous la main (les zone mémoires que le GC doit conserver). Le reste est « pure ».
On sait par expérience que ça tourne en une fraction de seconde, il n'y a aucune raison valable pour que ce genre de tâche ne soit pas déléguée à la chaine de compilation.
On peut de plus imaginer que cette optimisation soit facultative Dans le processus de compilation, et à ce moment la, les fonction pures sous réserve sont compilées comme « impures ».
C'est pourquoi D fait la différence entre class et struct. Dans le second, on est statique par défaut.Citation:
Envoyé par koala01
Ce n'est pas prendre les choses à l'envers, c'est tout simplement déléguer au compilateur le choix de décider dans des domaines ou il est capable de la faire aussi bien que nous.Citation:
Envoyé par koala01
Je crois que tu n'as pas bien comprit comment sont définis les fonction membres en D. Si la fonction est déclarée « final », alors l'appel est statique, identique à celui du C++. Si la fonction n'est pas finale, alors la fonction peut-être redéfinie dans des classes dérivées. C'est dans ce cas au compilateur de décider si la fonction doit-être virtuelle ou non. Cela signifie que si la fonction n'est pas surchargée dans des classes dérivées, alors le compilateur est libre de « dévirtualiser » la fonction.
Ainsi, le mot clef final n'a plus d'impact sur le code généré. C'est simplement un contrat que passe le programmeur, car il est important que cet appel ne soit pas virtuel.
Le choix par défaut est le comportement virtuel. mais cela ne signifie pas que toutes ces fonction doivent être virtuelles.
Je ne comprend pas qu'il n'en soit pas de même pour les fonctions pures.
Parce que pour moi la popularité est une conséquence des deux autres points. Un langage qui ne les remplirait pas ne serait pas populaire.Citation:
Envoyé par deadalnix
Const en C++ est une très bonne chose, c'est justement une chose qui me manque en Java, où on doit utiliser des workarounds comme Collections.unmodifiableList. Le problème du const C++ est qu'il n'est pas transitif comme le const D. À mon avis ça va changer beaucoup de choses dans un monde où le multithread devient la norme.
Par contre virtual, j'aurais préféré un virtual par défaut avec la possibilité de spécifier nonvirtual quand on est sûr que la méthode ne devra jamais être surchargée. Comme en D, quoi.
Tu pourrais préciser pourquoi ? J'aime pour ma par les défaut définis comme en C++. Tout d'abord d'un point de vue fainéantise : J'ai généralement bien plus de fonctions non virtuelles que de fonctions virtuelles. Ensuite de manière plus conceptuelles : Une fonction virtuelle est un point de variation de mon code. C'est donc un risque de problèmes, je doit plus encore que les autres fonction y faire attention, la documenter différemment, plus précisément. J'aime donc bien que ce ne soit pas ce que j'obtient comme comportement par défaut.Citation:
Envoyé par Niark13
Les deux points sont une condition nécessaire mais non suffisante.Citation:
Envoyé par Niark13
seul le linker permet de dire qu'une fonction sera pure ou non (car on a pas l'info sur les autres fonctions avant le linker). le code généré dépend de savoir si une fonction est pure ou non.
si en théorie il est tout a fait possible de savoir si une fonction est pure ou non, en pratique cela se sait trop tard pour générer le code optimisé. ou alors il faut une phase d'optimisation globale qui s'éxécute encore apres le linker. pourquoi pas, mais bon.
le fait est aussi que le mot clé const et pure sont des atouts pour la documentation, et quelque part je refuse de m'en séparer parce que des feignasses laissent le compilo se demmerder. j'aurai prefere que tout soit const par defaut en fait et le mot-clé mutable pour marquer ce qu'on a le droit de modifier.
mais je me sers beaucoup de const et je concois que quand on s'en sert pas on voit pas l'utilité (ou l'inverse). c'est aussi une des raisons pour laquelle je n'ai pas adheré a D.
de meme, virtual, je prefere le dire moi meme plutot que de laisser le compilo le faire. c'est une documentation.
il ne faut pas oublier que l'on passe plus de temps a relire du code qu'a l'ecrire, et peut etre le compilateur D est plus malin que le compilateur C++ mais le programmeur D n'est pas plus malin que le programmeur C++ et pour moi le désamour du D vient du fait qu'il est plus difficile a relire (implémentation mélangée avec déclaration, impossible a la lecture de savoir quelle implementation d'une fonction sera appelée, impossible de savoir a la lecture si une fonction est pure ou const, ca fait beaucoup a "deviner")
en bref ces quelques defauts transforment selon moi un outil de codage en un outil de bidouillage pour les gens qui sont seuls sur leurs projets dans leur garage, en quelque sorte.
Ce comportement est bon dans l'idéal. Il suppose que tu aies bien anticipé tes besoins futurs (ou ceux de tes utilisateurs si tu écris une bibliothèque).Citation:
Envoyé par JolyLoic
En pratique, il arrive que les besoins et le code n'évoluent pas comme on l'avait pensé au départ.
Je trouve le virtual par défaut plus souple.
Ça évite aussi certains problèmes qui peuvent survenir quand une fonction qui n'est pas virtuelle est surchargée par erreur.
Les performances ne sont pas vraiment un problème, le compilo pouvant détecter si une méthode n'est pas surchargée et la rendre non virtuelle voire l'inliner (si possible).
Et plus dangereux. Car on va introduire une variation là où le concepteur de la classe ne l'avait peut être pas imaginé. Je préfère comme dit précédemment l'inverse : par défaut non virtuel et virtuel explicitement.Citation:
Envoyé par Niark13
Je trouve ce point gênant : effectivement si une classe masque une fonction de la classe de base, on peut ne pas le savoir. Heureusement ;), C++0x a pensé à toi : les attributs devraient permettre de régler ce problème. Si j'ai bien compris, base_check permet de générer une erreur de compil si un tel masquage a lieu :Citation:
Envoyé par Niark13
Code:
2
3
4
5
6
7
8
9
10
11
Ce n'est pas si simple. Si l'objet est manipulé par référence ou pointeur, il a pu être obtenu dynamiquement (à partir d'un DLL plugin par exemple). Et donc le compilo ne sait pas s'il s'agit d'une classe dérivée ou non. Les seules optimisations qui peuvent avoir lieu sont quand la fonction virtuelle est appelée sur un objet par valeur (ou dans le constructeur et le destructeur ... mais là c'est souvent une erreur du développeur).Citation:
Envoyé par Niark13
J'en conçoit bien l'utilité. seulement, dans la pratique, il y a un tas de trucs chiants qui n'ont pas lieu d'être avec le const. Comme souvent en C++, ce n'est pas l'idée qui est mauvaise, mais la mise ne pratique.Citation:
Envoyé par screetch
Si je fait un accèsseur pour un donnée, du genre :
Si je l'appelle depuis un contexte ou this est const, je vais me faire appeler léon. Or, le compilo est tout à fait en mesure de "constifier" cette fonction. Je ne devrais avoir une erreur que si j'ai du code impliquant un non const dans getX.Code:
2
3
Le fait est que c'est gênant quand on a une erreur, mais sans plus. La ou c'est vraiment traitre, c'est si j'oublie un const quelque part, et que du coup j'appelle des versions non optimisée du code.
Or vient un moment ou tout est suffisamment complexe pour être sur qu'on va en laisser passer.
Le const par défaut est une solution, mais je ne crois pas que ce soit LA solution. LA solution est de garder le const, mais d'autoriser le compilo à « constifier ».
Il n'y a rien à deviner. Pourquoi ne pas préciser ces choses seulement si cela est pertinent, et laisser le compilateur se débrouiller dans les autres cas ?Citation:
Envoyé par screetch
C'est justement ça le rôle du compilateur : faire à ta place. Les arguments que tu donnes la sont sensiblement les mêmes que ceux ne voulant pas passer de l'asm au C il y a quelques années.
Ce qui est important, c'est qu'un comportement soit définis (que le programme fasse ce qu'il est supposé faire) et que le compilateur se débrouille pour que ça aille le plus vite possible.
Le fait de savoir si techniquement, une fonction est virtuelle ou non n'a pas d'importance. L'important est de savoir si je peux surcharger cette fonction ou non. Il peut-être important d'empêcher la surcharge, et c'est pourquoi on a final.
On peut résumer la spec de D à ce niveau de la sorte : une fonction est présupposée finale, sauf si elle est redéfinie dans une classe fille. Le choix de la finalité par défaut est la pour car c'est le choix le plus performant. Si l'on veux forcer ce choix, alors on utilises le mot clef final.
Ainsi, les choses sont sous contrôle seulement si cela est pertinent.
S'il est pertinent de spécifier qu'une fonction soit pure, alors elle doit être définie pure. Mais pourquoi ne pas présupposer toute fonction comme pure, à moins qu'elle ne fasse une opération impure ?
Ainsi, comme le mot clef final, cela devient un contrat à respecter. Le code généré, est lui, toujours le code optimal.
laisse de coté l'optimisation un moment, pense aux gens qui lisent ton code. ils ne sont pas comme le compilateur, capable d'aller verifier toute les implementations pour voir si la fonction est const ou pure ou finale ou virtuelle.Citation:
Envoyé par deadalnix
En D, la méthode surchargée hérite aussi des contrats d'entrée et de sortie de la méthode de la classe de base, ce qui permet de vérifier qu'elle se comporte correctement en mode debug. En pratique, je ne vois pas trop en quoi c'est inquiétant. Tu peux me donner un exemple ?Citation:
Envoyé par 3DArchi
Et cela n'a pas d'importance dans bien des cas.Citation:
Envoyé par screetch
Je me tape complètement de savoir si une fonction est virtuelle ou non quand je lis le code. Par contre, savoir si je peux la surcharger ou non est important. Et si je la surcharge, le compilo saura qu'elle doit être virtuelle. Mais toi, ce qui t'importe, c'est que tu puisses la surcharger.
Ce n'est pas grave de laisser le compilateur en faire plus. Mais je crois que tu ne comprend strictement rien à ce que je défend. Je ne défend pas la disparition de mots clef comme const ou pure, mais de simplement ne pas les rendre « contaminant ».
En l'occurrence, c'est leur absence qui est contaminante (si une méthode est déclarée comme const, aucune méthode l'appelant ne peut l'être).
Mais comme déjà dit par d'autres, ces qualificateurs apportent à l'auto-documentation. Si, par exemple, une fonction "to_upper" prend une std::string& en argument, il est fort probable que la fonction modifie la chaîne sur place. Si, à l'inverse, un itérateur dispose d'une méthode "getNextElement" déclarée const, l'on sait que son appel ne provoque pas un passage à l'élément suivant.
dans ce cas on peut dire que toi tu ne comprends pas ce que je dis. Tu prends encore l'exemple de quelqu'un qui ecrit du code quand je te demade de prendre l'exemple de quelqu'un qui lit du code.Citation:
Envoyé par deadalnix
J'ai du mal à comprendre, tu parles du D d'il y a plusieurs années alors ? Parce que, pour ce que j'en sais, D possède const et pure depuis bientôt 3 ans... const en D est d'ailleurs beaucoup plus contraignant qu'en C++...Citation:
Envoyé par screetch
Je connais des compilo C++ qui permettent de marquer pure une fonction et comme tu dis une phase d'optimisation globale va optimiser deux appels avec les mêmes arguments par exemple. Au link.Citation:
Envoyé par screetch
D'ailleurs en D le linker à moins de boulot. Pas besoin de virer des templates dupliqués quand tu compile toutes tes sources en même temps :mouarf:
La constness en C++ a relativement peu d'utilité à mon avis par rapport à la surcharge cognitive qu'elle entraine (const * const, mutable, const_cast, constexpr).Citation:
Envoyé par screetch
La const-correctness de D2 est bien différente. Elle vise à réparer le const C++ en le rendant transitif, répondre au besoin du constexpr C++1x, et permettre la parallélisation automatique.
Tout celà au prix d'une plus grande complexité (const, immutable, shared...)
D1 quant à lui à juste const qui a le rôle du constexpr de C++1x.
Là je suis d'accord, je n'aime pas virtual par défaut parce que j'oublie parfois de préciser final et que DMD ne sait toujours pas dévirtualiser des fonctions pas surchargées (comme Java le ferait).Citation:
Envoyé par screetch
Ce que tu avances équivaut à dire que Java est moins lisible que C++. Je ne pense pas. Un langage est d'autant plus difficile à lire qu'on ne le connait pas.Citation:
Envoyé par screetch
Là où en C++ je travaille sur des gros fichiers redondants, le D m'encourage a multiplier les petites classes qui ne font qu'une chose, dans des fichiers pas trop gros. Je trouve ça plus lisible.
C'est vrai que les headers permettent d'avoir un apercu global d'un classe bien pratique, mais en D rien n'empêche de les générer ces headers.
C'est un peu comme la différence entre Java et C++, à la différence que D:
- ne propose pas une méta-programmation tronquée
- n'a pas besoin de VM ni de Hotspot qui tourne en mémoire
Une attaque pas entièrement fausse.Citation:
Envoyé par screetch
Mais si D reste obscur, ce n'est probablement pas à cause de ces supposés défauts là mais probablement à cause d'un leader pas aussi charimatique qu'un Larry Wall ou un Guido, et du manque de support d'un géant de l'industrie.
En comparaison, quand Google sort Go, un langage à un stade d'avancement "là où était D il y a 7 ans" (dixit Alexandrescu), tous les bloggeurs de la planète ont une érection.
Attention de ne pas confondre les défauts du langage avec ceux du compilo ;)Citation:
Envoyé par ponce
Tu réfléchis quelques peu à l'envers...Citation:
Envoyé par deadalnix
Ici, si tu te fais appeler léon, tu n'a qu'à rendre ton accesseur constant, et le tour est joué...Mais...
Imaginons plutôt une fonction quelconque "doSomething" qui prenne une forme proche de
Il est impossible d'admettre que cette fonction ne modifie pas l'objet, car, même si c'est fait de manière indirecte (par appel d'une fonction qui appelle une fonction qui le modifie), le résultat est le même : l'objet est, bel et bien, modifié...Code:
2
3
4
5
6
Si tu invoque cette fonction dans un contexte ou this est constant, tu dois te faire rabrouer
Permettre au compilateur de rendre une fonction constante en cas de besoin serait, peut-être, une bonne chose, mais cela risque fort de ne pas fonctionner à tous les coups: ton accesseur pourrait profiter de cette capacité, mais doSomething ne le pourrait pas.
Dés lors, l'utilisateur pourrait très bien se trouver dans une situation dans laquelle deux instructions qui se suivent et dont la signature est strictement identique au niveau de la (non) constance seraient gérées différemment: acceptées pour l'accesseur, refusée pour doSomething 8O.
Cela ne facilite pas vraiment le boulot du programmeur :P
D'autant plus que l'erreur apparaitrait sur doSomething, qui est, justement, la fonction pour laquelle il est le plus difficile de remarquer qu'il est impossible de faire en sorte qu'elle s'engage à ne pas modifier l'objet en cours.
J'ai déjà fait part de mon avis sur le sujet: la règle de base doit être la moins restrictive possible et les restrictions doivent faire partie des règles particulières et être explicites
Imagine la manière dont il faudrait énoncer la règle permettant de déterminer si une année est bissextile (une année est bissextile si elle est divisible par 4 sauf si elle est divisible par 100 mais elle l'est par contre si elle est divisible par 1000) si la règle générale avait été "toute année est bissextile par défaut", et tu comprendra ton malheur...
HS : chuchote @koala c'est par 400, pas par 1000 ;)!Citation:
Envoyé par koala01
Bien sur ! La fonction ne sera pas toujours « constifiable ».Citation:
Envoyé par koala01
Oui, sauf qu'ici, le compilo te renvoie dans les choux, non pas parce que tu as oublié de marquer const, mais bien parce qu'en effet, ta fonction n'est pas const. Ce qui me semble une bien meilleure raison.Citation:
Envoyé par koala01
Si le message d'erreur est explicite, cela ne devrait pas poser de gros problèmes. S'il est important de spécifier explicitement le const, alors on peut aussi le faire.
Je ne crois pas que l'exemple sur les années bissextiles soit très évident. Mais si tu veux aller dans ce sens, ce que je propose, c'est que le compilo se débrouille tout seul pour savoir si une années est bissextile ou non. Et qu'on puisse le spécifier si cela est réellement important (cela a alors valeur de contrat).
Il me semble la politique pour const sera la-même que pour pure.
Le programmeur devra spécifier si la fonction est const, et le compilateur le vérifiera derrière. Le const_cast sera possible toutefois.
et je le redis, en temps que lecteur de code si je veux savoir si une fonction est const ou pas ? je compile dans ma tete?Citation:
Envoyé par deadalnix
Ce que cela a à voir, c'est qu'une règle générale se doit d'être... générale...Citation:
Envoyé par deadalnix
Seules les exceptions ou les règles particulières peuvent se permettre d'être... particulières.
Si tu commence à placer trop d'exceptions à la règle générale, c'est sans doute que ce que tu as considéré (visiblement à tord) dans un premier temps comme la règle générale était en réalité... une des exceptions ;)
En faisant en sorte que la constance doit être explicite, nous pouvons nous contenter d'une règle en trois points:
Si c'est la non constante qui devient implicite, et, surtout, si le compilateur doit être en mesure de déterminer si, oui ou non, une fonction peut être constante, tu auras beaucoup plus de mal à écrire des règles simples qui, en plus, permettent au lecteur du code de déterminer facilement s'il peut ou non invoquer telle ou telle fonction au départ d'un objet constant...
- une fonction peut être constante ou non
- toute fonction peut être invoquée au départ d'un objet donné sauf si
- <exception à la règle généale> l'objet en question est constant, auquel cas, seules les fonctions constantes peuvent être appelées.
D'où le parallèle avec les règles permettant de déterminer si une année est bissextile ou non: si tu pars d'une règle générale expliquant que toutes les années bissextiles, tu devra multiplier les exceptions à cette règle (et, partant, les exceptions aux exceptions), afin de coller à la réalité des faits ;)
Le const est loin d'être un cas particulier, et c'est bien le problème.
Je comprend qu'on puisse vouloir faire les choses à la main quand on est capable de faire mieux que le compilo, mais quand on ne l'est pas ?
Combien de fois on se tape des erreur de compilation car on a oublié un const (ou mis un de trop) ? Est-ce que cela est vraiment nécessaire sachant que ça peut se gérer automatiquement ?
Et, question subsidiaire, pourquoi est-ce réellement important de savoir si ce qu'on appelle est const ou non ?
tu reponds a une question par d'autres questions, c'est un peu agacant
Si c'est un cas particulier: tes objets sont non constants par défaut, et donc, par défaut, les fonctions qui ne s'engagent pas à ne pas modifier l'objet au départ duquel elles sont invoquées sont le cas général...Citation:
Envoyé par deadalnix
Même si tu manipule, dans certaines parties de code, beaucoup d'objet constants, tu manipule quand même, de manière générale, encore beaucoup plus d'objet non constants
Le problème n'est pas tant d'être capable ou non de faire mieux que le compilateur, le problème est de permettre au lecteur du code de le comprendre avec un maximum de facilité ou non...Citation:
Je comprend qu'on puisse vouloir faire les choses à la main quand on est capable de faire mieux que le compilo, mais quand on ne l'est pas ?
Un langage de programmation, quel qu'il soit, quel que soit le paradigme utilisé, n'est qu'un moyen qui nous est donné de nous faire comprendre à "quelque chose d'aussi bête qu'un ordinateur".
S'il en avait été autrement, nous en serions restés depuis des décennies au langage machine.
Mais la première qualité d'un code source, avant même de faire ce que l'on attend de lui, doit être d'être facilement compréhensible par l'humain, car il est beaucoup plus souvent lu qu'écrit ou modifié (write once read ever disent les anglo saxons...)
Permettre au compilateur de déterminer "par lui même" si une fonction est (peut être considérée comme) constante ou non alors qu'il devient difficile pour l'humain de le déterminer lors de la lecture fait perdre cette qualité première.
Oui, sans hésiter...Citation:
Combien de fois on se tape des erreur de compilation car on a oublié un const (ou mis un de trop) ?Est-ce que cela est vraiment nécessaire sachant que ça peut se gérer automatiquement ?
D'abord parce que cela permet au (re)lecteur du code de ne pas devoir (re)plonger dans plein de fonctions pour déterminer si une fonction appelée est bel et bien constante...
Ensuite, parce qu'il vaut mieux une erreur de compilation qu'une erreur d'exécution...
Tant qu'une erreur de compilation survient, tu ne perd "que" un peu de temps à la résoudre...
Lorsqu'une erreur d'exécution survient en présentation, il faut s'appeler microsoft pour que cela passe inaperçu voire normal ;)
Parce qu'il arrive que tu ne veuille absolument pas qu'un objet (passé par référence, par exemple) soit modifié...Citation:
Et, question subsidiaire, pourquoi est-ce réellement important de savoir si ce qu'on appelle est const ou non ?
De trop nombreux résultats erronés ou aberrants (quand ce ne sont pas des plantages magistraux) sont dus au fait qu'une modification a été apportée à un objet alors qu'elle n'avait pas lieu d'être.
Le respect de la constance (la "const correctness") t'oblige, effectivement, à réfléchir plutôt deux fois qu'une à ce que tu fais, mais te permet, en retour, d'éviter bien des déboires qui, la loi de murphy aidant, ne se feront jour qu'au pire moment que tu pourra imaginer ;)
Pour ma part j'ai tendance à croire que l'élément décisif pour qu'un langage puisse s'imposer reposait moins sur ses qualités intrinsèques que sur la qualité de son écosystème (EDI, bibliothèques, outils...). Cela suppose des investissements importants, en hommes et en ressources, que seules de grosses compagnies peuvent aujourd'hui se permettre. D'ailleurs il n'est pas étonnant que les derniers langages à avoir réussi à percer "récemment" (Java, C#) sont issus de telles organisations.
Personnellement j'ai de sérieux doutes qu'en à la capacité du D à percer, je pencherai plutôt sur le langage GO de Google (même si ce dernier est, à l'heure actuelle, loin d'être parfait).
Afin d'être certain de bien comprendre ce que tu entends par laisser faire le compilo, je voudrait reformuler ce que j'ai cru comprendre :Citation:
Envoyé par deadalnix
On peut déclarer une fonction const. A ce moment, elle va vérifier :
- Qu'elle ne modifie rien directement
- Qu'elle n'appelle que des fonction déclarées comme const ou des fonction non déclarées comme const, mais qui sont const quand même (c'est à dire qui ne provoqueraient pas d'erreur de compilation si on les déclarait const elles aussi).
C'est bien ça ?
Si oui, quelques questions :
- Comment faire pour les cas où le const permet de choisir entre deux fonctions surchargées, ça ne pose pas de problème de mauvaise fonction appelée si un const est omis ?
- Pour que ce système puisse marcher, il faut un système de compilation moins séparé qu'en C++, où pour appeler une fonction, il faut non seulement avoir sa déclaration, mais aussi des informations complémentaires ajoutées par le compilateur. N'est-ce pas problématique ? Comme de plus ces informations dépendent de l'implémentation d'une fonction, modifier une implémentation peut demander à recompiler plein de code. Comment est-ce géré ?
Non, mais de bon outils peuvent améliorer la situation, en signalant ces erreurs en cours de frappe, sans passer par un cycle de compilation complet.Citation:
Envoyé par deadalnix
S'il est aussi important de le savoir à la relecture, c'est justement pour éviter de se manger une erreur de compil dans les dents.Citation:
Envoyé par koala01
Le seul moment ou il est justifié de spécifier const, c'est s'il y a un traitement différent à faire. Tout le reste n'est que complexité inutile, et pas qu'a l'écriture.
EDIT, car on a posté en même temps :
Oui, c'est exactement ça.Citation:
Envoyé par JolyLoic
Le compilo doit « constifier » au maximum.Citation:
Envoyé par JolyLoic
Pour la compilation : non, ce n'est pas un problème. C'est fait en java par exemple. Pire, en java le chargement dynamique de code est possible, ce qui nécessite de faire ce genre d'opérations en « live » pendant l'exécution du programme. En fait, il faut que le compilateur place des tags dans les objets, et que le linker finalise des bouts de code en fonction.Citation:
Envoyé par JolyLoic
Pour les cas des DLL par exemples, c'est typiquement le genre de cas ou il faut spécifier ce genre de truc explicitement. Sinon pour le reste, avec des fichier objets bien foutus, c'est le linker qui prend en charge le tout, donc pas de recompilation nécessaire.
De la même façon que pour la purification, les algo mis en jeux s'exécutent très rapidement.
Bonjour,
personnellement je suis tout à fait d'accord avec la FAQ, sur le fait qu'une classe doit se construire plutôt de l'extérieur que de l'intérieur. Or le fait de laisser le compilateur décider de la constance d'un méthode, cela revient à laisser l'implémentation définir l'interface (soit tout l'opposé :?).
De plus, le const signifie que la fonction ne modifie pas l'objet dans son concepte. Une fonction peut très bien ne pas modifier un objet en apparence (c'est-à-dire que l'on aurait pu la marquer const sans que cela n'empèche la compilation), alors que son action modifie tout de même "l'état" de l'objet.
Vite un exemple, car dit comme ça c'est assez obscure :aie: :
pour un conteneur type vecteur, qui implémente une sémantique de valeur, une fonction Elt_t & operator[](size_t Index) non const pour très bien être marquée comme telleSi le compilateur décidait, il la considérerait à tort const :( ...Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
...Ou pour mettre une erreur de conception en évidence...Citation:
Envoyé par deadalnix
Si tu détermines, à un moment donné qu'un objet n'a aucune raison d'être modifié mais qu'un appel de fonction modifie cet objet, que ce soit de manière directe ou indirecte, c'est que tu as, très clairement, "foiré" ta conception quelque part ;)
Si tu laisse le compilateur gérer la constance des fonctions, et que, pas de bol, il n'arrive pas à rendre une fonction constante du fait des appels impliqués, non seulement tu perds, comme je l'ai déjà signalé, la qualité première du code, mais, en plus, tu te mangera une erreur à l'exécution, ce qui est encore bien pire que si c'était "simplement" une erreur de compilation.
Non, il est justifié de le faire chaque fois que ton analyse et ta conception mettent clairement en évidence que l'objet n'a pas lieu d'être modifié...Citation:
Le seul moment ou il est justifié de spécifier const, c'est s'il y a un traitement différent à faire. Tout le reste n'est que complexité inutile, et pas qu'a l'écriture.
Commence par te demander pourquoi tu pourrais vouloir rendre un objet constant...
La raison principale est, sans doute, que tu veux le passer en argument à une fonction en évitant la copie de l'objet, mais que tu souhaites qu'il ne soit pas modifié par la fonction que tu appelles...
Pour éviter la copie, tu n'as pas beaucoup le choix, tu passera sans doute l'objet par référence comme paramètre à la fonction appelée.
Le fait de le passer sous la forme d'une référence aura d'autres avantages qui sortent largement du débats, et que je ne citerai donc pas ici ;)
Pour éviter tout risque que la fonction appelée ne modifie l'objet, tu le passera sous la forme d'une... référence constante.
Le fait de passer un argument sous la forme d'une référence constante a un autre avantage: celui de permettre l'utilisation d'une variable temporaire non nommée.
Une variable temporaire non nommée est une variable qui ne porte aucun nom dans la fonction appelante, dont on n'a besoin que le temps de l'appel de la fonction, et donc, à laquelle il sera impossible d'accéder en dehors de la fonction appelée.
Comme Il est impossible d'accéder à cette variable dans la fonction appelante, il n'y a aucun sens à en permettre la modification.
C'est le phénomène que l'on observe avec un code proche de
grâce à la présence d'un constructeur non explicite dans la classe std::string prenant un const char * en argument (selon l'exemple) et agissant comme... opérateur de conversion de const char * en std::string.Code:
2
3
4
5
6
7
8
9
10
Comme une variable temporaire non nommée n'existe que le temps de l'appel de la fonction et qu'il est impossible d'y accéder depuis la fonction appelante, il n'y a strictement aucun intérêt à en permettre la modification dans la fonction appelée...
C'est la raison pour laquelle la manoeuvre est autorisée pour... les références constante (permettant, par ailleurs, d'éviter la copie si l'objet passé en argument n'est pas une variable temporaire non nommée).
La deuxième raison qui pourrait t'inciter à employer la constance réside, même si je n'aime pas à y avoir recours, dans la définition d'accesseurs...
En effet, lorsque tu définis un accesseur sous la forme de
tu obtiens, encore une fois, une copie de m_x, avec, encore une fois, tous les problèmes liés au fait qu'il y a copie (nécessité que Type soit copiable, utilisation parfois massive de mémoire, temps de copie parfois excessif, ...)Code:
2
3
4
La solution au seul problème de copie est donc, encore une fois, de renvoyer le membre par référence, mais, si tu renvoie une référence non constante, un code proche de
aura pour résultat... la modification de l'objet en cours (c, dans l'exemple)...Code:
2
3
4
Ce qui risque fort de poser problème vu que foo n'est pas sensée modifier c...
Et, pour notre malheur, un code proche de(getX, getY et getZ renvoyant des objets de types différents sous la forme de références)Code:
2
3
4
5
pourrait être tout à fait valide si ni les références renvoyées par getX, getY et getMachinChose, ni les dites fonctins n'étaient constantes...
Mais nous aurions alors modification de ce qui est renvoyé par getMachinChose qui, fatalement, signifie la modification de ce qui est renvoyé par getY, qui implique la modification de ce qui est renvoyé par getX... qui implique la modification de... c...
Si tu laisse faire le travail au compilateur, il y a une chance sur deux pour... qu'il accepte le code en utilisant la version non constante de getX, getY et getMachinChose et une chance sur deux... pour qu'il la refuse...
S'il la refuse, tu aura, de toutes manières, une erreur de compilation, mais, s'il l'accepte, tu risques, au mieux, d'avoir des résultats finaux aberrants...
Si, dés le départ, le lecteur du code voit que getX renvoie... une référence constante, il saura qu'il ne peut pas modifier ce qu'elle renvoie, de même pour getY et getMachinChose.
Il saura donc qu'il ne peut pas décider de modifier ce qui est renvoyé par getMachinChose.
De leur coté, la constance des fonctions getX, getY et getMachinChose assurent la cohérence au niveau des différents objets renvoyés:
A partir du moment où une des fonctions sera déclarée constante, nous seront surs que le compilateur nous enverra paitre si, pour une raison ou une autre, les fonctions membres invoquées au départ de l'objet renvoyé ne prennent pas, elles-aussi, l'engagement de ne pas modifier l'objet en cours...
Encore une fois, nous pourrions dire que le compilateur pourrait déduire la constance de la fonction (ce qui, ici, nécessiterait sans doute de connaitre l'implémentation des fonctions getX, getY et getMachinChose...:P:aie:8O), sauf que, non seulement, nous perdons, ici encore, la qualité primordiale du code, mais, en plus, il risque de considérer à tord les différentes fonctions comme étant... non constantes...
Ce à quoi je veux en venir, c'est que, si même on venait (quelle horreur) à s'en foutre le la première qualité d'un code, il serait excessivement dangereux de s'en remettre au compilateur pour déterminer l'engagement que prend (ou non) une fonction à ne pas modifier l'objet en cours...
C'est la raison de l'existence du mot clé mutable lorsqu'il s'agit de gérer un "cache" ne devant être remis à jour que sous certaines conditions...Citation:
Envoyé par gb_68
C'est plus ou moins le phénomène que l'on peut rencontrer dans une liste:
size_ (selon l'exemple) n'est recalculé que si l'objet a été modifié depuis le dernier appel à... sizeCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
J'aurais même encore fait plus simple pour cette fonction:Citation:
Vite un exemple, car dit comme ça c'est assez obscure :aie: :
pour un conteneur type vecteur, qui implémente une sémantique de valeur, une fonction Elt_t & operator[](size_t Index) non const pour très bien être marquée comme telleSi le compilateur décidait, il la considérerait à tort const :( ...Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
Mais ce n'est qu'un détail ;)Code:
2
3
4
5
6
Le compilo n'est pas la pour gérer l'engagement. Il est la pour dire « mon programmeur n'a pas marqué ceci comme const, mais en fait ça l'est, ne lui renvoyons pas une erreur dans les gencives et compilons quand même ».Citation:
Envoyé par koala01
Tu donnes de bons exemples ou il est utile de spécifier explicitement le const. le soucis, c'est que pour que tout cela fonctionne bien, il va falloir par la suite que je colle du const partout dans mon programme, et j'ai pas mal de chance d'avoir à un moment ou a un autre à me battre avec.
Ce que tu mets en valeur, c'est que ce qui est dangereux, c'est la « déconstification ».
Ce que je propose, c'est que :
1/ Les choses soient non const par defaut (cas générique). Le compilo de décider de « constifier » si cela l'est dans la pratique.
2/ Il est possible de spécifier explicitement que quelque chose est const. Dans ce cas, le compilo est chargé de vérifier que la contrat est bien respecté.