> Tout en finesse, comme tes remarques sur PbPg...
> Pour le virtual, je t'explique.
Alors là c'est toi qui est gonflé ! Pourquoi rappeler tout ceci alors que je le sais pertinemment, je ne n'aurais pas parlé sur ce sujet sinon ? N'importe quel programmeur C++ doit savoir ça, c'est la base pour la partie objet. Le fait est que si tu veux que tous tes objets aient le comportement que tu attends, dès le départ tu dis dans ton projet « toutes les fonctions membres seront virtuelles », et c'est fini. Aucune difficulté. Seulement ce qui ne te plait pas c'est que le comportement qui te sert le plus nécessite un mot clé. C'est du délit de sale gueule, il n'y a pas d'autre argument "contre".
> Dans un langage objet qui fonctionne, toutes les méthodes sont "virtuel" par défaut. Si on a besoin d'interdire la redéfinition, on utilise un mot clé adapté, comme "final" en Java.
Non. C'est un choix dans la conception du langage, point. De plus C++ n'est pas objet mais propose un support pour la programmation OO, c'est différent. Il n'a pas prétention à être un langage objet. Bref, tu lui donnes des prétentions et tu le critiques dessus, alors je dis que c'est ridicule. Le support OO est présent, point. Si ce n'est pas le langage qui te convient, prends-en un autre plus adapté à ton projet. Mais le simple fait de devoir marquer « virtual » des fonctions n'est certainement pas un élément déterminant pour exclure C++. Tes qualifications de « boiteux » et autre sont totalement subjectives. C++ n'a pas vocation à être simple à apprendre mais puissant à l'utilisation. Il nécessite un investissement plus grand en apprentissage, mais c'est payant au bout du compte. L'apprendre à la légère n'est pas une option, mieux vaut utiliser un langage plus simple à apprendre.
> Le plus convainquant est celui qui dit que cela facilite l'interfaçage avec du C en ayant des objets sans table des méthodes virtuelles.
Je ne sais pas si ça nécessite un argument, mais ce serait bien que tu cites ceux qui ont réellement été pris en compte et pas ceux que tu as pu lire ici ou là. Des fanatiques du C++ ont pu te sortir n'importe quel mauvais argument, moi ce qui m'intéresse serait le raisonnement de Stroustrup et du comité. Pour ma part, c'est juste un choix du langage et j'utilise la syntaxe qui va bien en fonction de ce que je veux faire.
> On peut alors passer leur contenu à des fonctions C sans soucis. On peut aussi "encapsuler" une struct C en un objet C++ en ajoutant des méthodes. Sauf qu'on sait depuis des années comment faire ça proprement : avec des objets "lights" comme dit Guillaume, c'est-à-dire des objets qui sont manipulables par valeur (contrairement aux objets de Java) et qui ne supportent pas l'héritage.
Mais tout ça ce sont des questions de conception justement. Tu dois savoir si tu utilises tes objets avec une sémantique de valeur ou d'identité, tu les définis en fonction de ça, et pour ça tu utilises le langage. C++ n'impose pas une seule sémantique contrairement à Java, donc tu as plus de choix, plus d'efforts à faire sur la conception et sa transposition en code.
> Voilà, voilà, tu vois, je connais un peu le sujet, mais bon, vu ton aggressivité déplacée, je suppose que tu t'en fous.
Non, mais ce qui ne m'intéresse pas, c'est des arguments contre des arguments qui ne m'intéressent pas. Si tu vois passer des arguments pipeau pour virtual, ça ne m'intéresse pas de voir ce que tu dis contre eux, parce que moi-même ils ne m'ont pas convaincu. J'aurais d'ailleurs préféré que C++ ait le comportement que tu dis ! Seulement ce n'est vraiment pas bien grave, la solution est tellement triviale (déclarer correctement) que c'est tout sauf un argument contre C++ : C++ a bien d'autres problèmes qui font qu'on préférera d'autres langages à celui-ci, mais le "virtual" comme problème insoluble n'est vraiment pas sérieux. Si tu veux faire de l'objet à la Java en C++, tous tes objets ont des fonctions membre virtuels et tu les utilises avec une sémantique d'identité, autant que possible avec des références, sinon des pointeurs, et jamais directement. Je ne dis pas que l'apprentissage nécessaire pour bien s'en servir est comparable à Java ou autre sur ce point là.
Je vois que tu n'as pas cité de références vers les arguments officiels qui ont mené à la syntaxe avec virtual. Un discours constructif aurait commencé par ça, il me semble.
[^] # Re: C'est un troll.
Posté par Bière Drabo . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 0.
> Pour le virtual, je t'explique.
Alors là c'est toi qui est gonflé ! Pourquoi rappeler tout ceci alors que je le sais pertinemment, je ne n'aurais pas parlé sur ce sujet sinon ? N'importe quel programmeur C++ doit savoir ça, c'est la base pour la partie objet. Le fait est que si tu veux que tous tes objets aient le comportement que tu attends, dès le départ tu dis dans ton projet « toutes les fonctions membres seront virtuelles », et c'est fini. Aucune difficulté. Seulement ce qui ne te plait pas c'est que le comportement qui te sert le plus nécessite un mot clé. C'est du délit de sale gueule, il n'y a pas d'autre argument "contre".
> Dans un langage objet qui fonctionne, toutes les méthodes sont "virtuel" par défaut. Si on a besoin d'interdire la redéfinition, on utilise un mot clé adapté, comme "final" en Java.
Non. C'est un choix dans la conception du langage, point. De plus C++ n'est pas objet mais propose un support pour la programmation OO, c'est différent. Il n'a pas prétention à être un langage objet. Bref, tu lui donnes des prétentions et tu le critiques dessus, alors je dis que c'est ridicule. Le support OO est présent, point. Si ce n'est pas le langage qui te convient, prends-en un autre plus adapté à ton projet. Mais le simple fait de devoir marquer « virtual » des fonctions n'est certainement pas un élément déterminant pour exclure C++. Tes qualifications de « boiteux » et autre sont totalement subjectives. C++ n'a pas vocation à être simple à apprendre mais puissant à l'utilisation. Il nécessite un investissement plus grand en apprentissage, mais c'est payant au bout du compte. L'apprendre à la légère n'est pas une option, mieux vaut utiliser un langage plus simple à apprendre.
> Le plus convainquant est celui qui dit que cela facilite l'interfaçage avec du C en ayant des objets sans table des méthodes virtuelles.
Je ne sais pas si ça nécessite un argument, mais ce serait bien que tu cites ceux qui ont réellement été pris en compte et pas ceux que tu as pu lire ici ou là. Des fanatiques du C++ ont pu te sortir n'importe quel mauvais argument, moi ce qui m'intéresse serait le raisonnement de Stroustrup et du comité. Pour ma part, c'est juste un choix du langage et j'utilise la syntaxe qui va bien en fonction de ce que je veux faire.
> On peut alors passer leur contenu à des fonctions C sans soucis. On peut aussi "encapsuler" une struct C en un objet C++ en ajoutant des méthodes. Sauf qu'on sait depuis des années comment faire ça proprement : avec des objets "lights" comme dit Guillaume, c'est-à-dire des objets qui sont manipulables par valeur (contrairement aux objets de Java) et qui ne supportent pas l'héritage.
Mais tout ça ce sont des questions de conception justement. Tu dois savoir si tu utilises tes objets avec une sémantique de valeur ou d'identité, tu les définis en fonction de ça, et pour ça tu utilises le langage. C++ n'impose pas une seule sémantique contrairement à Java, donc tu as plus de choix, plus d'efforts à faire sur la conception et sa transposition en code.
> Voilà, voilà, tu vois, je connais un peu le sujet, mais bon, vu ton aggressivité déplacée, je suppose que tu t'en fous.
Non, mais ce qui ne m'intéresse pas, c'est des arguments contre des arguments qui ne m'intéressent pas. Si tu vois passer des arguments pipeau pour virtual, ça ne m'intéresse pas de voir ce que tu dis contre eux, parce que moi-même ils ne m'ont pas convaincu. J'aurais d'ailleurs préféré que C++ ait le comportement que tu dis ! Seulement ce n'est vraiment pas bien grave, la solution est tellement triviale (déclarer correctement) que c'est tout sauf un argument contre C++ : C++ a bien d'autres problèmes qui font qu'on préférera d'autres langages à celui-ci, mais le "virtual" comme problème insoluble n'est vraiment pas sérieux. Si tu veux faire de l'objet à la Java en C++, tous tes objets ont des fonctions membre virtuels et tu les utilises avec une sémantique d'identité, autant que possible avec des références, sinon des pointeurs, et jamais directement. Je ne dis pas que l'apprentissage nécessaire pour bien s'en servir est comparable à Java ou autre sur ce point là.
Je vois que tu n'as pas cité de références vers les arguments officiels qui ont mené à la syntaxe avec virtual. Un discours constructif aurait commencé par ça, il me semble.