Discussion :

[screetch]

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.

[deadalnix]

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).

[Florian Goo]

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.

[yan]

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-Write

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
uchar *QImage::bits()
{
    if (!d)
        return 0;
    detach();
    return d->data;
}

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
const uchar *QImage::bits() const
{
    return d ? d->data : 0;
}

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.

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.

[Klaim]

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é.

[deadalnix]

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.

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.

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.

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.

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.

[Invité]

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.

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).

[koala01]

Le mot clef const est juste une erreur de conception du C++ selon moi.

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".

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:

• création d'un objet "modifié"
• assignation de l'objet modifié à l'argument
• destruction de l'objet d'origine

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).

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).

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).

Oui, à condition d'effectuer une étude complète et récursive de la fonction...

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

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.

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".

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...

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.

Ce point de vue peut, effectivement, se défendre, mais, à mon sens (encore une fois), il a tendance à traiter le problème à l'envers:

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.

[deadalnix]

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 ».

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...

C'est pourquoi D fait la différence entre class et struct. Dans le second, on est statique par défaut.

Ce point de vue peut, effectivement, se défendre, mais, à mon sens (encore une fois), il a tendance à traiter le problème à l'envers:

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.

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.

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.

[Niark13]

Tu oublies un paramètre tout bête : la popularité.

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.

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.

[JolyLoic]

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.

[deadalnix]

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.

Les deux points sont une condition nécessaire mais non suffisante.

[screetch]

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.

[Niark13]

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'obtiens comme comportement par défaut.

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).
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).

[3DArchi]

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).
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.

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.

Ça évite aussi certains problèmes qui peuvent survenir quand une fonction qui n'est pas virtuelle est surchargée par erreur.

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
struct base
{
   void non_virtual_function();
};
 
struct  [[base_check]] derived : public base
{
   void non_virtual_function(); // error : fonction masquée.
   void non_virtual_function [[hiding]]  (bool yes_i_can);// hiding permet de dire qu'on sait ce que l'on fait.
};

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).

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).

[deadalnix]

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.

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.

Si je fait un accèsseur pour un donnée, du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
A getX(){
    return this->x;
}

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.

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 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")

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 ?

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.

[screetch]

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.

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.

[Niark13]

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.

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 ?

[deadalnix]

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.

Et cela n'a pas d'importance dans bien des cas.

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 ».

[spidermario]

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.