Discussion :

[Alp]

Enfin, sans concepts, pas d'axiomes non plus, et là, je ne vois rien qui puisse faire comme ces derniers.

Ce qui est dommage, c'est qu'on ne savait pas trop à quoi s'attendre pour les axiomes... On va dire qu'on a du mal à voir comment le compilo peut en faire quelque chose.

[screetch]

si GCC avait un support direct du D (sur toute les plate formes, sans qu'il soit exterieur) alors D serait plus populaire.

[loufoque]

Tu trouve qu'il est plus clair et plus concis plutôt que de définir deux concepts et de faire de l'overloading basé dessus de définir une classe de trait, et d'avoir une fonction qui dispatch l'appel vers deux fonctions avec un paramètre bidon permettant de lire la classe de traits ?

Mais de quoi tu parles ?
Je trouve qu'il est plus clair de définir ce qu'est un concept avec une suite d'expressions valides plutôt qu'avec une signature. Ça ne compose pas très bien avec le genre de fonctionnalité que proposent les concept_map, par contre.

Sans compter que pour moi, la fonctionnalité principale des concepts qui est la détection d'erreur, je ne vois pas trop comment l'émuler. Avec des checks, on peut valider que le type de l'utilisateur répond bien aux contraintes (mais de manière peu élégante, je trouve), mais je ne crois pas qu'on puisse valider que l'implémentation n'utilise rien d'autre que ce qu'elle croit utiliser.

Pour ça, on instancie l'algorithme avec un archétype, ce qui réalise un test de recouvrement, et qui est en effet un peu plus de travail. Mais ça ne concerne que l'auteur de la fonction, pas son utilisateur (et il me semble que les messages d'erreurs plus clairs, c'est un truc demandé par les utilisateurs de bibliothèques templates plus que par leurs auteurs).

Enfin, sans concepts, pas d'axiomes non plus, et là, je ne vois rien qui puisse faire comme ces derniers.

Les axiomes permettent au compilateur de présupposer certaines choses pour faire des optimisations éventuelles.
En particulier, ne faire aucune optimisation est une implémentation valide.
Une émulation (à moins qu'elle ne soit couplée à un optimiseur d'expressions Boost.Phoenix ou que sais-je) ne ferait aucune optimisation.

[mister3957]

J'ai du mal à comprendre pourquoi il faut absolument trouver un successeur au C++

[Arzar]

Mais de quoi tu parles ?

Du même exemple qu'a donné Florian, je suppose.

Ceci :

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
//overload for list nodes
template<ListNode SyntaxNodeT>
SyntaxNodeT
convert_node(const tree_node_t& node)
{
return convert_list_node(node);
}
 
//overload for optional nodes
template<OptionalNode SyntaxNodeT>
SyntaxNodeT
convert_node(const tree_node_t& node)
{
return convert_optional_node(node);
}

au lieu de :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
 
//overload for list nodes
template<class SyntaxNodeT>
SyntaxNodeT
convert_node
(
const tree_node_t& node,
typename boost::enable_if<syntax_nodes::utility::is_list_node>::type* = 0
)
{
return convert_list_node(node);
}
 
//overload for optional nodes
template<class SyntaxNodeT>
SyntaxNodeT
convert_node
(
const tree_node_t& node,
typename boost::enable_if<syntax_nodes::utility::is_optional_node>::type* = 0
)
{
return convert_optional_node(node);
}
 
/*
* Utility types
*/
typedef char yes_type;
 
struct no_type
{
char padding[8];
};
 
 
 
/*
* list_node type trait
*/
namespace list_node_check
{
template<class T>
static
yes_type
check_sig(typename T::item*);
 
template<class T>
static
no_type
check_sig(...);
}
 
template<class T>
struct is_list_node
{
static const bool value = sizeof(list_node_check::check_sig(0)) == sizeof(yes_type);
};
 
 
 
/*
* optional_node type trait
*/
template<class T>
struct is_optional_node
{
static const bool value = false;
};
 
template<class T>
struct is_optional_node<syntax_nodes::optional_node>
{
static const bool value = true;
};

Leur enlèvement ne change rien en pratique car leurs fonctionnalités s'émulent sans problème avec une syntaxe comparable (je dirais même plus claire et concise).

Très drole.

Et pourtant, bizarrement, dans pas mal d'entreprise, la politique c'est PAS DE TEMPLATE, car justement personne n'arrive à comprendre et maintenir ce genre de "syntaxe comparable claire et concise" à base de boue illisible de SFINAE, traits et autres hacks.

[loufoque]

Comparons.

Définition de concept :

Code :

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

1
2
3
4
5
auto concept Foo<typename T>
{
    typename type = typename T::type;
    void T::bar();
};

Code :

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

1
2
3
4
5
6
7
8
9
10
template<typename T>
struct Foo
{
    typedef typename T::type type;
 
    BOOST_CONCEPT_USAGE(Foo)
    {
        make<T>().bar();
    }
};

Je dirais que la solution 2 est plus intuitive, pratique et puissante, plus en relation avec la réalité (ce qu'on veut, c'est tester que des expressions sont valides, pas des signatures), d'autant plus qu'elle s'intègre mieux dans le langage (un concept est un type, donc on peut le manipuler comme tel).

Ensuite, l'usage :

Code :

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

1
2
3
4
template<typename T>
requires Foo<T>, Assignable<T>
void
use_a_foo(const T&);

Code :

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

1
2
3
4
5
template<typename T>
BOOST_CONCEPT_REQUIRES(
   ((Foo<T>))((Assignable<T>)),
   void
) use_a_foo(const T&);

Bien entendu, il faut une macro, mais c'est pas la mort.

Alternativement on peut aussi faire

Code :

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

1
2
3
4
5
6
template<typename T>
void use_a_foo(const T&)
{
    BOOST_CONCEPT_ASSERT(Foo<T>);
    BOOST_CONCEPT_ASSERT(Assignable<T>);
}

ce qui est un peu moins bien, puisque les concepts n'apparaissent pas dans la signature de la fonction. (et donc par conséquent ne peuvent pas être utilisés pour la résolution de surcharge, mais est-ce vraiment important)

[koala01]

Salut,

Pour en revenir au noeud du problème, je peux t'assurer que les "chroniques d'une mort annoncées" d'un langages ont eu lieu de tous temps...

Et, de tous temps, elles se sont révélées n'être que des mirages, quel que soit le langage (utilisé de manière professionnelle) visé ou le temps laissé pour qu'elles se réalisent...

Le bémol que l'on peut émettre, c'est que certains langages se sont retrouvé limités à des secteurs de niches particuliers, mais, dans l'ensemble, dés que tu as des développements étalés sur dix ans avec un langage précis, il est souvent plus facile et moins onéreux de trouver "la perle rare" qui connait le langage et de continuer à l'utiliser que reprendre le développement intégral dans un autre langage

Cela a été le cas avec Ada, Cobol, et C quand un nouveau langage a été annoncé (je me demande même si, concernant fortran, il n'y aurait pas eu prophétie identique à la sortie de C), et, pourtant, ils sont toujours utilisés

De plus, la décision prise concernant les concepts en C++ ressemble plus à un ajournement concernant leur mise au point qu'à un abandon définitif

Sans compter le fait que ce n'est pas parce qu'une feature particulière n'est pas adoptée que, forcément, cela implique que le langage subira une "perte de vitesse", même si cette feature semble importante

Tout cela pour te dire qu'il "n'est pas impossible" que l'absence des concepts fasse que certains nouveaux programmeur décident de ne pas l'utiliser, mais qu'il y a encore de la marge pour en arriver au fait que cette absence décide ceux qui l'utilisent à changer de langage

Ceci dit, mon avis personnel est qu'il est bon d'être "spécialisé" dans un langage particulier, mais que cela n'empêche absolument de connaitre au minimum les bases des autres, et qu'il est même souhaitable d'être en mesure de se débrouiller avec

Il n'est pas souhaitable de vouloir les maitriser parfaitement tous, car à trop vouloir savoir tout faire, on en vient à ne rien savoir faire correctement, mais c'est malgré tout une bonne chose que d'être en mesure de poser un oeil attentif sur un code écrit dans un autre langage que celui dans lequel on est "spécialisé" et d'arriver à comprendre ce qui est fait

[Florian Goo]

Merci Koala, c'est très rassurant pour moi de lire tout ceci

[LittleWhite]

So, mettons nous tous au D \o/

[deadalnix]

Bon alors sur proposition de Florian Goo, je relance le topic.

Tout d'abords, pour que vous cituiez le personnage, je suis un utilisateur expérimenté de C++, mais surtout un utilisateur de D bien que j'ai bien moins d'expérience dans ce langage.

Dans un premier temps, soyons réaliste : D ne va pas tuer C++. C++ à un tel passif qu'il ne va pas disparaitre du jour au lendemain. On a un tas de libs en C++, tout plein de programmeurs expérimentés, et c'est une techno connue vers laquelle un décideur se tournera plus facilement qu'une techno moins connues (dissonance cognitive tout ça).

D propose de faire du C++ à l'envers. En C++, on part bas niveau, mais, avec divers outils comme les smart pointers, ce que tous le monde utilise de nos jours, on s'élève à un niveau supérieur.

D propose de coder haut niveau d'origine, mais de descendre bas niveau quand cela est nécessaire. Ce qui est à mon avis une meilleur approche étant donné la proportion de code haut niveau vs bas niveau dans une appli standard.

Par exemple, la mémoire alloué l'est par défaut par un GC, mais on peut décider d'utiliser le mécanisme de notre choix.

Ou bien les fonction membres d'une classe sont virtuelle par défaut. On précise qu'elles en le sont pas à l'aide du mots clef final, se besoin est.

Pour moi, D, c'est ce qu'aurait du être le C++ si on l'avait conçu avec l'expérience qu'on a maintenant.

J'ai vu ici que D avait été conçu par des théoriciens. Mon avis d'utilisateur est diamétralement opposé. En connaissant C++, j'ai juste l'impression de coder plus facilement sans me sentir vraiment plus limité. La syntaxe est plus simple, les bugs moins nombreux (ou détectés plus tôt/facilement), et ça compile vite !

D'ailleurs, ça compile suffisamment vite pour que D puisse être utilisé en langage de scripting. Le compilateur dmd fournis déjà cette possibilité.

Parmi les choses sympathiques, il y a par exemple les unitest, les lazy évaluation pour les paramètres de fonction, les templates sont bien mieux pensées qu'en C++, permettent de faire plus plus simplement (C++0x propose des choses intéressantes la dessus, mais tout est déjà dans D), la surcharge d'opérateur est aussi mieux pensée.

Voila pour D1. D2 promet bien plus, notamment sur le multithreading, ou l'approche est vraiment intéressante. D2 est un peu le C++0x version D, le truc génial qui peine à venir.

Maintenant D souffre de quelques soucis de jeunesse. Il y a deux lib standard en compétition (sic) ce qui n'aide pas à s'y retrouver au début, et google est bien prolifique en réponses qu'avec C++ (bien qu'on ai généralement moins de questions aussi).

La compatibilité avec C est très bien assurée, mais pas avec C++. Ceci est principalement du au fait que noms ne sont pas standardisées en C++, ce qui pose des soucis quand il faut lier le tout. Si appeler du code C est facile, D rompt la compatibilité au niveau syntaxique, ce qui est le principal défaut de C++ selon moi. Repartir sur une base saine et fraiche, c'est a mon avis ce qu'il faut à C++.

Bref, c'est pour moi une bonne solution pour un projet tout neuf. Mais il faut savoir être réaliste, réutiliser l'existant est un gros point fort de C++.

[Florian Goo]

Le D différencie allocation sur la pile et sur le tas, et donc permet le RAII. Ça c'est fort bien !

Ou bien les fonction membres d'une classe sont virtuelle par défaut. On précise qu'elles en le sont pas à l'aide du mots clef final, se besoin est.

Ça par contre j'aime moins. J'ai bien plus de fonctions membres « finales » que virtuelles dans mes codes…
Enfin, vu qu'on a plus de chances de s'exclamer « ah ben voilà pourquoi ça bugue, j'avais oublié de rendre la fonction virtuelle ! » que la même chose avec s/virtuelle/finale.
Après tout, les variables sont mutables par défaut en C++. C'est certainement plus cohérent.

Maintenant D souffre de quelques soucis de jeunesse. Il y a deux lib standard en compétition (sic) ce qui n'aide pas à s'y retrouver au début

Fichtrement rédhibitoire, non ?

La compatibilité avec C est très bien assurée, mais pas avec C++. Ceci est principalement du au fait que noms ne sont pas standardisées en C++, ce qui pose des soucis quand il faut lier le tout.

Je ne sais plus où j'ai entendu parler de volonté de standardisation de l'ABI C++. Dans C++0x, peut-être ?
Si on pouvait utiliser du C++ aussi bien que du C en D, ce serait un essor formidable.

[Invité]

Si on pouvait utiliser du C++ aussi bien que du C en D, ce serait un essor formidable.

Oui, à la limite, une compatibilité "partielle" avec le C++, qui permettrait, disons, d'utiliser les principaux frameworks d'UI, et d'interfacer D avec la masse de code "C with classes" existant donnerait au langage une chance dans le monde professionnel.

C'est, mine de rien, ce qui a contribué au succès initial du C++: partant d'un gros existant C, on pouvait assez facilement lui ajouter des bouts de C++, et ainsi de suite. C'est aussi ce qui a fait que le C++ traine toujours, 20 ans après, cet héritage...

Francois

[Florian Goo]

La possibilité d'utiliser des libs C++ serait déjà intéressante.
EDIT : Grâce à Scalpel (voir signature), on pourrait envisager un générateur de binding.

Rendre possible l'inclusion directe de C ou C++ dans du code D serait reproduire l'erreur commise par le C++… la même « erreur » qui a permis des migrations de gros programme de C vers C++, certes.

[deadalnix]

Ça par contre j'aime moins. J'ai bien plus de fonctions membres « finales » que virtuelles dans mes codes…
Enfin, vu qu'on a plus de chances de s'exclamer « ah ben voilà pourquoi ça bugue, j'avais oublié de rendre la fonction virtuelle ! » que la même chose avec s/virtuelle/finale.
Après tout, les variables sont mutables par défaut en C++. C'est certainement plus cohérent.

C'est très pragmatique :
- Une fonction virtuelle qui ne devrait pas l'être ne va pas poser de gros problèmes, si ce n'est une indirection lors de l'appel. Ce qui est en fait insignifiant dans la plupars des cas (cela n'est signifiant que si la fonction est destinée à être appelée très souvent).
- Le compilo peut optimiser de lui même en « finalisant » une méthode.

Mais bon, visiblement, ton message montre que tu as bien comprit ce point.

De plus, D fait une différence très nette entre classe et structure.

Dans une classe les méthodes sont virtuelles par défaut. On y fait de l'héritage, et toutes les classe héritent de la classe Object. Bref, on est dans le paradigme objet a fond les ballons.

Dans le cas de la structure, on ne peut pas avoir de méthodes virtuelles ni d'héritage. Il y a fort a parier que nombre de tes classes C++ devraient être en fait traduite en D par des structures plutôt que des classes.

Fichtrement rédhibitoire, non ?

Je ne te le fais pas dire !

Je ne sais plus où j'ai entendu parler de volonté de standardisation de l'ABI C++. Dans C++0x, peut-être ?
Si on pouvait utiliser du C++ aussi bien que du C en D, ce serait un essor formidable.

Non, je n'ai pas entendu parler de ça. Ça serait d'ailleurs un sacré problème étant donné le passif qu'on a en C++ de changer l'ABI comme ça. Mais c'est aussi un sacré problème d'être dans le merdier qu'on a actuellement à ce sujet. je penses que c'est l'un des faiblesses du C++, mais celle-ci étant historique, il sera très dur de revenir dessus.

D prévoit de s'interfacer avec le C++, mais ce problème d'ABI fait que cela a été reporté à plus tard.

[deadalnix]

EDIT : Grâce à Scalpel (voir signature), on pourrait envisager un générateur de binding.

Ça ne résout pas le problème de l'ABI, mais c'est clairement une partie de la solution.

Rendre possible l'inclusion directe de C ou C++ dans du code D serait reproduire l'erreur commise par le C++… la même « erreur » qui a permis des migrations de gros programme de C vers C++, certes.

Sur ce point, D à fait quelque chose d'intéressant. S'il est trivial d'appeler du code C depuis D, la compatibilité syntaxique est rompue.

Pour importer des lib bien connues, on peut faire :

import std.c.stdio

Ce qui revient à inclure stdio.h .

Pour des choses personnalisées :
extern (C) int foo(int a); //Pour cdecl
extern (Windows) int foo(int a); //Pour stdcall

Bref, rien de plus simple. On compile le C d'un coté, le D de l'autre, et on lie tout ensemble.

[Florian Goo]

Sur ce point, D à fait quelque chose d'intéressant. S'il est trivial d'appeler du code C depuis D, la compatibilité syntaxique est rompue.

Oui, c'est la fameuse « erreur » à laquelle je faisais allusion (mais que tu as mieux formulée que moi ).

[koala01]

<snip>
De plus, D fait une différence très nette entre classe et structure.

Dans une classe les méthodes sont virtuelles par défaut. On y fait de l'héritage,

Ca, ca ne me gène absolument pas, et je trouve d'ailleurs l'idée "raisonnable" par contre

et toutes les classe héritent de la classe Object.

Ca, ca me gène déjà beaucoup plus...

Mais c'est un travers repris par plus d'un langage.

Je comprend le principe, mais cela signifie:

1. que tu *risque* de te retrouver avec une arborescence d'héritage comprenant un nombre élevé de niveaux là où deux ou trois auraient suffit sans cet héritage "d'office"
2. que LSP est, à tout le moins, envisagé d'un coté bizarre de la lorgnette, car quel pourrait bien être le point commun (récupéré de Object) entre une classe voiture, une classe chien et une classe pomme
3. Que l'héritage multiple, s'il est autorisé, finit immanquablement en héritage en losange, voir en diamant, avec les problèmes que cela comporte (mais peut être est-ce géré d'une manière ou d'une autre par le langage )

Bref, on est dans le paradigme objet a fond les ballons.

Je vais peut être te surprendre, mais, plus ça va, plus j'ai l'impression que l'on considère à tord le paradigme objet comme la solution miracle à tous les maux.

Attention, n'allez pas me faire dire ce que je n'ai pas dit: je trouve énormément de qualités au paradigme objet...

Mais cela n'empêche que j'estime que son potentiel est encore bien plus large s'il est couplé, par exemple, avec le paradigme générique, voire, pourquoi pas, avec une petite dose de procédural pur (une bonne fonction libre, éventuellement générique peut éviter pas mal de circonvolutions qui seraient nécessaires si on devait s'en tenir au seul paradigme objet)

Dans le cas de la structure, on ne peut pas avoir de méthodes virtuelles ni d'héritage. Il y a fort a parier que nombre de tes classes C++ devraient être en fait traduite en D par des structures plutôt que des classes.

Très certainement, et je citerais en premier les classes ayant sémantique de valeur

Mais, en C++ la distinction entre une classe et une structure est à ce point ténue (elle tient dans la visibilité par défaut de la classe/structure) qu'il est tout à fait possible d'utiliser indifféremment l'un pour l'autre

[Florian Goo]

Tiens, il m'avait échappé le coup de la classe Object… je ne suis pas fan non plus.
Concernant l'héritage multiple en losange, diamant ou parallélépipède rectangle, pas de problème puisque l'héritage multiple n'est pas autorisé.

Je te rejoins sur l'exagération de la suprématie du paradigme objet. En revanche il me semble que les fonctions libres sont autorisées en D, donc fausse alerte.

[koala01]

Tiens, il m'avait échappé le coup de la classe Object… je ne suis pas fan non plus.
Concernant l'héritage multiple en losange, diamant ou parallélépipède rectangle, pas de problème puisque l'héritage multiple n'est pas autorisé.

C'est un choix qui se vaut, mais auquel j'ai malgré tout le plus grand mal à adhérer, même si je le respecte...

La raison est, sommes toutes, des plus simple, mais je lui trouve une certaine importance:

Cela t'oblige à prendre en compte les restrictions imposées par le langage alors que tu n'est encore que très loin d'envisager ne serait-ce que la première ligne de code, du moins, dans un process idyllique de mise au point d'une application.

Je m'explique:

A la base de la mise au point, il y a (normalement) une analyse des besoins, des cas d'utilisation et tout plein de chose qui, au final, déboucheront sur un ou plusieurs diagrammes de classes.

Et il est plus que vraisemblable que, à un moment donné, tu en vienne à te dire que "ce serait pas mal si ma classe C héritait de ma classe A et de ma classe B", dans le plus pur respect de LSP.

Mais, c'est à ce moment là que tu te rappelle que "mince, zut, flute, j'avais oublié: le langage que j'utilise n'autorise pas l'héritage multiple"... Et encore, cela implique que celui qui s'occupe de la conception sache quel sera le langage utilisé (re )

Alors, de deux choses l'une:

Ou bien celui qui s'occupe de la conception en connait "suffisamment" sur le langage pour savoir qu'il doit éviter l'héritage multiple, mais il se retrouve confronté à devoir faire des circonvolutions pour "faire avec" cette limite.

Ou bien il ne connait pas la limite (ou décide de ne pas en tenir compte, ce qui serait bien pire, mais qui arrive surement), et c'est le pauvre type chargé de l'implémentation qui doit, au mieux, demander à ce que l'on refasse le travail (avec le surcout et la perte de temps que cela implique), au pire se "démerder" et ne pas suivre le "plan" que l'on a tracé pour lui.

Mais soyons clair sur un point: c'est un reproche que je fais de manière générale à tout langage qui place ce genre de restriction... Même si j'arrive à m'y faire lorsque je suis obligé d'utiliser un tel langage

[EDIT]Je précise que, selon moi, une bonne conception (ou un bon algorithme, d'ailleurs) devrait pouvoir être totalement indépendant du langage dans lequel il ou elle sera implémenté et que ce n'est, en tous cas, pas au langage de placer des restrictions "arbitraires"...

[Florian Goo]

Depuis le moment où j'ai appris l'existence des principes « préférez la composition à l'héritage » et « une classe hérite pour être réutilisée dans un contexte polymorphe et non pour réutiliser les fonctions de la classe mère » , je n'ai pas rencontré de cas où l'héritage multiple s'imposait (sauf pour les bidouilles du style boost::noncopyable ou boost::enable_shared_from_this, qui n'auraient pas lieu d'être en D).

Je ne suis pas un grand fan du Java, mais j'ai fini par concéder qu'un système à base d'héritage simple et d'interfaces était suffisant voire supérieur et à imiter en C++.