Discussion :

[Klaim]

Code :

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

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

Personellement ça me semble raisonnable effectivement. D'ailleurs, est-ce que le point 1 ne serait pas une optimization possible qu'un compilateur C++ actuel pourrait faire (ou fait déjà) ? Je sais que Visual Studio permet une optimization globale de l'application (je sais plus si ça l'est par défaut) et peut être que ça fait partie des optimizations effectuées, a bien y réfléchir ça me semble faisable.

[koala01]

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

Rien ne t'empêche pour l'instant d'invoquer une fonction membre constante au départ d'un objet constant...

La fonction membre size() de n'importe quelle collection de la STL est constante, et, pourtant, le code suivant est tout à fait correct:

Code :

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

1
2
3
4
5
6
7
8
int main()
{
    std::vector<int> tab;
    /* remplissage du tableau */
    size_t s=tab.size();
    /*utilisation de s */
    return 0;
}

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.

Non pas te battre avec...

Il ne faut pas considérer le compilateur comme un ennemi, bien au contraire: c'est ton meilleur allié.

C'est lui qui va t'aider à respecter tes engagements et une saine logique dans le cas où un objet est constant avant l'étape fatidique de l'exécution, parce qu'à ce moment là, il sera trop tard, et, loi de murphy aidant, toujours de nature à te mettre dans une situation peu enviable.

Ce que tu mets en valeur, c'est que ce qui est dangereux, c'est la « déconstification ».

Bien sur...

Il n'y a aucun danger à permettre invocation d'une fonction constante au départ d'un objet non constant...

Ce n'est pas le fait d'ajouter des restrictions qui est dangereux, c'est le fait d'en retirer

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

C'est ce qui se fait...

[EDIT] Du moins, si on entend par "constifier si besoin" le fait de considérer un objet non constant comme un objet constant[/EDIT]
A la différence près que tu semblais suggérer que le compilateur puisse déterminer si, effectivement, une fonction est constante ou non, et là, je dit NON

Le comportement du compilateur se doit d'être clairement déterminé dans une situation donnée.

On ne peut pas se permettre de lui laisser la possibilité de choisir "ce qui est le mieux" du point de vue de la conception si l'auteur du code ne précise rien.

Si tu lui laisse cette possibilité, il y aura toujours une chance sur deux qu'il... choisisse la mauvaise.

Au final, le choix est simple:

Soit on part (comme c'est le cas actuellement) du principe que les fonctions membres sont non constantes sauf indication explicite du contraire, soit on part du principe que les fonctions membres sont constantes sauf indication explicite du contraire.

Si tu essaye de partir du principe que les fonctions membres sont non constantes mais que, si l'auteur du code ne l'indique pas, il se peut qu'elles soient, malgré tout constantes, et que c'est au compilateur de vérifier ce qu'il en est, tu t'apprête à foncer droit dans un mur...

[koala01]

Il faut bien se rendre compte que le compilateur a un travail à faire, et que c'est déjà bien suffisant: fournir un code exécutable.

Pour ce faire, il doit suivre trois règles:

• respecter la syntaxe et la grammaire du langage
• s'assurer le la cohérence de la conception
• faire en sorte que le programmeur respecte ses engagements

On ne peut absolument pas lui demander de prendre des décisions de conception...

Ce serait un peu comme de demander à une machine de concevoir une application et de la programmer sans avoir recours à la main d'oeuvre humaine.

Je sais que les films comme terminator ou I robot on beaucoup déliré sur l'idée, mais on est encore loin d'y arriver

[screetch]

je refuse que des feignasses fassent du code pas propre en disant "le compilo va optimiser tout ca". c'est la meme excuse qui pousse les gens a dire "mais la performance de ce code n'est pas critique". un ingenieur software se doit de pondre le code sans erreur et adapté et pas de pecher par feignantise.
je pars du principe exactement inverse, une fonction devrait etre const par defaut et un mot clé devrait signaler que la fonction modifie l'objet. tout comme on devrait signaler qu'une fonction est virtelle.

ce n'est _pas_ le job du compilateur de completer l'interface, c'est le job d'un architecte logiciel. quelqu'un qui ne comprend pas ca n peut pas travailler en equipe

pour moi ca se range dans la categorie "avoir un nom de fonction qui explicite ce que fait la fonction dans son ensemble". parce que la lecture du code on la fait principalement dans l'interface, pas dans l'implementation.

[screetch]

et pour completer sur le topic general, a la lueur des derniers posts je me rends compte que D n'est pas un langage orienté industrie, c'est un langage orienté recherche. il est tres abouti d'un point de vue theorie du langage (templates tres puissants, multi paradigmes) mais ne passe pas le "crash test" de la pratique; des problemes plus delicat comme le partage du code entre programmeurs et les outils associés sont en retard sur le reste de l'industrie.

[deadalnix]

Franchcment, cette remarque ne peut objectivement tenir la route.

Tout d'abords parce que java par exemple fait la même chose, et qu'il a très bien passé le crash test comme tu dis. Ensuite, car question illisibilité, le C++ se pose quand même la.

[screetch]

le C++ a amené une plus grande facilité de partage du code par rapport a C, qui a contribué a le rendre populaire.
C# et Java sont des langages (comme le C++ ne me fait pas dire ce que j'ai pas dit) tres imparfaits mais des iterations sur les outils ont permis d'aider grandement a la productivité (exemple, le "folding" dans l'editeur permet de cacher les implémentations)
le D n'apporte ni beaucoup plus de puissance ni plus d'aide a la relecture ni des outils efficaces, c'est costaud de s'imposer comme cela.

il me semble que trop de temps a été passé sur la puissance/vitesse du compilateur et sur des details interessants au niveau du langage en delaissant ce dont l'industrie a reellement besoin, et je maintiens quelque part que le D n'est pas un langage de partage de code. Le C++, en fait, encore moins. Si un langage doit innover pour etre adopté par l'industrie c'est peut etre par la qu'il faudrait passer? ou alors dans les outils pour le rendre plus facile d'acces.

[_skip]

Je suis pas tout à fait d'accord avec ce qui a été dit dans le post précédent mais c'est vrai qu'une palette d'outils et un IDE puissant aide beaucoup une technologie à gagner en popularité.

D'ailleurs les librairies graphiques préférées sont souvent celles qui offrent les meilleurs designers visuels, donc la meilleure productivité.

[Invité]

et pour completer sur le topic general, a la lueur des derniers posts je me rends compte que D n'est pas un langage orienté industrie, c'est un langage orienté recherche pour des codeurs hippies qui codent dans leur garage. il est tres abouti d'un point de vue theorie du langage (templates tres puissants, multi paradigmes) mais ne passe pas le "crash test" de la pratique; des problemes plus delicat comme le partage du code entre programmeurs et les outils associés sont en retard sur le reste de l'industrie.

Oui en D c'est pénible de partager du code à cause de la séparation Phobos/Tango ou D1/D2.

En C++ c'est pénible à cause de la séparation GCC/MSVC/autre, boost/pas boost, RTTI/pas RTTI, STL/pas STL, Qt/pas Qt, fromage/dessert.

Un langage qui débarque ne peut pas vraiment avoir un environnement aussi utile et stable que les standards de l'industrie. Il y a bel et bien des efforts d'intégration (IDEs spécifiques, intégration Eclipse etc...) mais pas forcément les ressources pour faire tout ce que les gens demandent ("je veux que ca marche sur ARM", "je veux un plugin pour le support dans Visual Studio...").

Et puis pour construire la réputation d'un langage il faut convaincre des gens à la fois dans l'industrie et dans l'académie, c'est comme ca parce que les thésard ont du temps. D reste tout de même beaucoup moins académique qu'Haskell et Scala.

Bref, pour une fois que quelqu'un propose un langage qui n'est pas moins-puissant-que-C++ et qui promet une belle économie de ressources, on lui reproche de ne pas avoir de bouton "fold" dans une IDE. Le serpent se mort la queue.

[deadalnix]

J'ajouterais que code block à une intégration sympatique de D. Ça ne vaut pas visual studio, mais c'est vraiment sympatoche.

[Niark13]

et pour completer sur le topic general, a la lueur des derniers posts je me rends compte que D n'est pas un langage orienté industrie, c'est un langage orienté recherche. il est tres abouti d'un point de vue theorie du langage (templates tres puissants, multi paradigmes) mais ne passe pas le "crash test" de la pratique; des problemes plus delicat comme le partage du code entre programmeurs et les outils associés sont en retard sur le reste de l'industrie.

Pour moi, les derniers posts n'ont pas parlé de D, mais étaient une digression sur l'utilité de d'utiliser un const implicite/explicite.

Pour rappel, D utilise un const explicite, comme le prouve ce code, qui foire à la compilation

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
import std.stdio;
 
class Toto
{
public:
    void f() const
    {
        writefln("Toto.f()");
    }
 
    void g() 
    {
        writefln("Toto.g()");
    }
}
 
void main(string[] args)
{
    const Toto t = new Toto;
    t.f();
    t.g(); // Erreur "Toto.g () is not callable using argument types () const"
}

Code testé avec DMD 2.039 sous Mac OS X 10.6.2.

[MenshaKaine]

C++ legends Scott Meyers, Herb Sutter, and Andrei Alexandrescu think about these things, too — all the time. Scott and Herb are neck-deep in C++0x, while Andrei is literally writing the book on D (The D Programming Language). Herb and Andrei put the pedal to the metal on applied concurrency and parallelism; Herb is writing the book on that topic (Effective Concurrency). All three focus on the development of high-performance systems, a topic Scott’s writing a book about (Fastware!).

Andrei Alexandrescu ecrirait un bouquin sur le D !

http://herbsutter.wordpress.com/

[Goten]

C'est pas nouveau :p. Sa fait un moment qu'il est attendu. (LA référence sur le D).

[Invité]

C'est un hippie, je parie qu'il écrit son livre dans un garage

[Klaim]

Ce n'est pas nouveau, au début du thread je parlais justement de discussions a propos du D qui ont été déclenchées après la publication d'un article d'Alexandrescu et il y a effectivment mention du bouquin.

Ce qui est interessant c'est que visiblement le bouquin va certainement servir de spécification pour mieu fixer le language. Ca me semble pas tout a fait pratique mais bon...

Sinon Alexandrescu est aussi star-developer sur le language, il y participe activement.

[Niark13]

Sinon Alexandrescu est aussi star-developer sur le language, il y participe activement.

Oui, au départ il me semble qu'il devait se concentrer sur la bibliothèque standard, mais il a pris de plus en plus d'importance. L'aspect général du langage a bien changé d'ailleurs sous son influence.
Il a d'ailleurs prévu des nouveaux changements importants dans le langage : par exemple le mécanisme de surcharge d'opérateurs devrait être refondu avant la publication de son livre, qui coïncidera avec la stabilisation de D2.

[oxyde356]

Le jour de la fin du C++ n'est pas là et je pense qu'elle est encore très très loin, ce langage permet de tout faire, et le nombre indénombrable de bibliothèques et frameworks qui permettent de l'étendre à tout les domaines et toutes les applis codées avec sont là pour en attester. C++ c'est vraiment l'équilibre parfait entre l'homme et la machine niveau langage (Java et C# sont bien trop loin de la machine pour moi quoi qu'en pense Microsoft), il y a certes quelques défauts mais il n'y a pas besoin d'un autre langage pour le remplacer, il suffit de modifier l'existant, et vu les possibilités...

[Invité]

Le jour de la fin du C++ n'est pas là et je pense qu'elle est encore très très loin, ce langage permet de tout faire, et le nombre indénombrable de bibliothèques et frameworks qui permettent de l'étendre à tout les domaines et toutes les applis codées avec sont là pour en attester. C++ c'est vraiment l'équilibre parfait entre l'homme et la machine niveau langage (Java et C# sont bien trop loin de la machine pour moi quoi qu'en pense Microsoft), il y a certes quelques défauts mais il n'y a pas besoin d'un autre langage pour le remplacer, il suffit de modifier l'existant, et vu les possibilités...

Qui a dit que C++ allait disparaître ?
Enfin bon, si tu penses que C++ est un parfait équilibre c'est probable que le D ne t'intéressera pas.

[Invité]

ce langage permet de tout faire

Juste une liste de choses que je ne peux pas faire en C++ aujourd'hui:
- CTFE
- arrays ops
- slices
- propriétés
- import
- auto
- templates mixins
- nested functions
- de pas écrire de headers
- constexpr ("const")
- pas besoin de preprocesseur
- compiler en 2 sec un programme en entier (200 ms pour du link incrémental)

alors qu'avec D1 je peux et je le fais aujourd'hui.
Je précise que le C++, j'en vis et que merci je le connais.

[Klaim]

Sans douter de tes connaissances, quelques reflexions :

- CTFE

Tu peux préciser stp? Je connais pas cet acronyme...

- arrays ops

Je ne suis pas sur de comprendre non plsu ce que tu entends par là?

- slices

Là par contre je ne vois pas bien en quoi en D il y a un avantage par rapport a C++, un slice a priori, est de toutes manière dépendant du conteneur ou des fonctions qui l'effectuent non?

- propriétés

Cette feature est pour le moins contestée au niveau C++... a mon avis avec ou sans c'est pas très important.

- import

Oui, tout ce qui est module est problématique en C++, visiblement le problème sera (avec de la chance) travaillé pour le TR2 (après c++0x).

- auto

Sera disponible dans C++0x et est aujourd'hui déjà implémenté dans des compilateurs récents comme gcc 4.4.x (si je me trompe pas) et le prochain vc10 qui devrait être officiellement dispo dans quelques mois et dont la beta est déjà dispo.

- templates mixins

Pas d'avis là dessus personellement.

- nested functions

Possibles a partir de C++0x via les lambda.

- de pas écrire de headers

Je ne comprends pas ce point : tu peux tout a fait coder sans header si tu n'as pas de types communs a tes différents cpp... ?

- constexpr ("const")

Ca arrive avec C++0x

- pas besoin de preprocesseur

Je ne comprends pas non plus : si tu n'utilise pas de commandes de préprocesseur, alors il ne sera pas utilisé. Ou alors j'ai mal compris ce que tu veux dire?

- compiler en 2 sec un programme en entier (200 ms pour du link incrémental)

C'est clair! D'après ce que j'ai lu sur le net, il se peut que si un systeme de module est mis en place, cela aiderai à largement accélérer la compilation. Mais je n'ai pas suivi les détails, je dis peut être des bêtises. En tout cas, rendre la compilation rapide aiderai grandement au niveau organisations iteratives façon scrum parcequ'on perdrait moins de temps a récupérer une version pour du feedback.