Vu d'un néophyte (pas débutant, mais pas très bon), quelles
différences y a-t-il entre Java et C++, mis à part quelques petites
particularités syntaxiques (syntaxe de création d'un tableau,
l'utilisation de destructeur d'objet, l'initialisation par défaut des
champs) ? Est-ce que l'héritage multiple change vraiment quelque chose
?
Où puis-je trouver un document clair (français ou anglais) qui me
permette de faire la transition (j'ai lu un article disant que C/C++
était plus rapide que Java et nécessitait moins de lignes) ?
Merci d'avance.
PS: laisse tomber les posts de Dany et Jérôme Martinez, ils sont partiellement faux (surtout ceux de Jérôme). Comme j'écris ça je vais devoir argumenter, mais aujourd'hui j'ai la flemme alors j'attends un peu qu'ils me hurlent dessus... :-)
J'attend juste de savoir ce qui est faux dans ce que j'ai dit... Je suis curieux.
Vincent wrote:
PS: laisse tomber les posts de Dany et Jérôme Martinez, ils sont
partiellement faux (surtout ceux de Jérôme). Comme j'écris ça je vais
devoir argumenter, mais aujourd'hui j'ai la flemme alors j'attends un
peu qu'ils me hurlent dessus...
:-)
J'attend juste de savoir ce qui est faux dans ce que j'ai dit... Je suis
curieux.
PS: laisse tomber les posts de Dany et Jérôme Martinez, ils sont partiellement faux (surtout ceux de Jérôme). Comme j'écris ça je vais devoir argumenter, mais aujourd'hui j'ai la flemme alors j'attends un peu qu'ils me hurlent dessus... :-)
J'attend juste de savoir ce qui est faux dans ce que j'ai dit... Je suis curieux.
kanze
Martinez Jerome wrote in message news:<bg2t3g$...
James Kanze wrote:
Sans parler de l'aspect risque. Quand j'étais à la Dresdner Bank, ils ont décidé de réécrire toute une application en Java, parce que la bibliothèque de fenêtrage sur laquelle elle était basée était retirée du marché.
D'ou l'interet de l'open-source...
Et qu'est-ce qu'open-source change dans ce cas ?
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Martinez Jerome <jerome.martinez@aenlever-orangefrance.com> wrote in
message news:<bg2t3g$68r3@news.rd.francetelecom.fr>...
James Kanze wrote:
Sans parler de l'aspect risque. Quand j'étais à la Dresdner Bank,
ils ont décidé de réécrire toute une application en Java, parce que
la bibliothèque de fenêtrage sur laquelle elle était basée était
retirée du marché.
D'ou l'interet de l'open-source...
Et qu'est-ce qu'open-source change dans ce cas ?
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Sans parler de l'aspect risque. Quand j'étais à la Dresdner Bank, ils ont décidé de réécrire toute une application en Java, parce que la bibliothèque de fenêtrage sur laquelle elle était basée était retirée du marché.
D'ou l'interet de l'open-source...
Et qu'est-ce qu'open-source change dans ce cas ?
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Arnaud Debaene
Vincent wrote:
Je suppose que la programmation par contrat consiste à créer une classe abstraite avec des méthodes abstraites, ce qui force tous ceux qui doivent créer des sous-classes de cette classe à définir un certain nombre de méthodes. Pas exactement l'idée c'est plutôt de s'assurer que le contrat de
chaque méthode soit respecter, par exemple qu'un argument de la fonction n'est pas nul, ou que l'appel de telle fonction n'est effectuée que dans une état donné de l'objet.
Mais là encore je ne suis pas tout à fait d'accord avec Kanze en fait java permet tout à fait ce genre de chose. Pour les arguments et pour une autre discussion sur C++ et Java (a propos de la qualité) voir le fil "Pour ou contre un code 100% objet" sur fr.comp.objet.
Et comment u fais en Java pour faire une classe qui "implémenteé deux interfaces au snes donné par James (c'est-à-dire avec pre-conditions et post-conditions) ? Sans héritage multiple d'implémentation, je ne vois pas comment on pourrait s'en sortir.
Arnaud
Vincent wrote:
Je suppose que la programmation par contrat consiste à créer une
classe abstraite avec des méthodes abstraites, ce qui force tous ceux
qui doivent créer des sous-classes de cette classe à définir un
certain nombre de méthodes.
Pas exactement l'idée c'est plutôt de s'assurer que le contrat de
chaque méthode soit respecter, par exemple qu'un argument de la
fonction n'est pas nul, ou que l'appel de telle fonction n'est
effectuée que dans une état donné de l'objet.
Mais là encore je ne suis pas tout à fait d'accord avec Kanze en fait
java permet tout à fait ce genre de chose. Pour les arguments et pour
une autre discussion sur C++ et Java (a propos de la qualité) voir le
fil "Pour ou contre un code 100% objet" sur fr.comp.objet.
Et comment u fais en Java pour faire une classe qui "implémenteé deux
interfaces au snes donné par James (c'est-à-dire avec pre-conditions et
post-conditions) ? Sans héritage multiple d'implémentation, je ne vois pas
comment on pourrait s'en sortir.
Je suppose que la programmation par contrat consiste à créer une classe abstraite avec des méthodes abstraites, ce qui force tous ceux qui doivent créer des sous-classes de cette classe à définir un certain nombre de méthodes. Pas exactement l'idée c'est plutôt de s'assurer que le contrat de
chaque méthode soit respecter, par exemple qu'un argument de la fonction n'est pas nul, ou que l'appel de telle fonction n'est effectuée que dans une état donné de l'objet.
Mais là encore je ne suis pas tout à fait d'accord avec Kanze en fait java permet tout à fait ce genre de chose. Pour les arguments et pour une autre discussion sur C++ et Java (a propos de la qualité) voir le fil "Pour ou contre un code 100% objet" sur fr.comp.objet.
Et comment u fais en Java pour faire une classe qui "implémenteé deux interfaces au snes donné par James (c'est-à-dire avec pre-conditions et post-conditions) ? Sans héritage multiple d'implémentation, je ne vois pas comment on pourrait s'en sortir.
Arnaud
Gabriel Dos Reis
"Arnaud Debaene" writes:
| Les | templates ne servent pas qu'à faire des conteneurs de T, loin de là.
| Les | templates ne servent pas qu'à faire des conteneurs de T, loin de là.
ah bon ?!
-- Gaby
pr.nm
(Vincent) wrote in message news:...
Pour la perf il ne faut pas se leurrer la vitesse d'éxécution d'une appli dépend d'abord de la qualité du programmeur. Et a mon avis un bon programmeur java doit pouvoir déculotter un programmeur moyen en C++. Oui, c'est également ce que dit l'article : la variance est très
grande et le critère fondamental n'est pas le langage utilisé mais le programmeur.
Globalement ta question est un peu vague, pour obtenir une bonne réponse précise si tu souhaite te former à un des deux langages sans but applicatif précis, ou si tu as une application (ou un domaine d'application) en tête dis-nous laquelle, sans quoi tu n'auras pas de réponse complète et pertinente à ta question. Je voulais faire principalement deux choses (en ce moment), en dehors
de progresser en programmation (ce qui, par expérience, ne se fait qu'en programmant) : un administrateur d'IA pour un jeu, et des algorithmes d'optimisation (toutes les méthodes utilisées en math.app., du data minig AG-réseaux de neurones jusqu'à des méthodes systématiques de recherche opérationnelle). Pour clarifier la première partie, l'idée est de créer un programme qui reçoit le code de sous-classes de la classe abstraite IA, et qui les fait jouer les unes contre les autres pour les comparer. Bien sûr, de pair à ce projet, il y a la programmation d'une de ces IA. Endymion
vclassine@elan.fr (Vincent) wrote in message news:<9e49e584.0307280504.515584ab@posting.google.com>...
Pour la perf il ne faut pas se leurrer la vitesse d'éxécution d'une
appli dépend d'abord de la qualité du programmeur. Et a mon avis un
bon programmeur java doit pouvoir déculotter un programmeur moyen en
C++.
Oui, c'est également ce que dit l'article : la variance est très
grande et le critère fondamental n'est pas le langage utilisé mais le
programmeur.
Globalement ta question est un peu vague, pour obtenir une bonne
réponse précise si tu souhaite te former à un des deux langages sans
but applicatif précis, ou si tu as une application (ou un domaine
d'application) en tête dis-nous laquelle, sans quoi tu n'auras pas de
réponse complète et pertinente à ta question.
Je voulais faire principalement deux choses (en ce moment), en dehors
de progresser en programmation (ce qui, par expérience, ne se fait
qu'en programmant) : un administrateur d'IA pour un jeu, et des
algorithmes d'optimisation (toutes les méthodes utilisées en
math.app., du data minig AG-réseaux de neurones jusqu'à des méthodes
systématiques de recherche opérationnelle). Pour clarifier la première
partie, l'idée est de créer un programme qui reçoit le code de
sous-classes de la classe abstraite IA, et qui les fait jouer les unes
contre les autres pour les comparer. Bien sûr, de pair à ce projet, il
y a la programmation d'une de ces IA.
Endymion
Pour la perf il ne faut pas se leurrer la vitesse d'éxécution d'une appli dépend d'abord de la qualité du programmeur. Et a mon avis un bon programmeur java doit pouvoir déculotter un programmeur moyen en C++. Oui, c'est également ce que dit l'article : la variance est très
grande et le critère fondamental n'est pas le langage utilisé mais le programmeur.
Globalement ta question est un peu vague, pour obtenir une bonne réponse précise si tu souhaite te former à un des deux langages sans but applicatif précis, ou si tu as une application (ou un domaine d'application) en tête dis-nous laquelle, sans quoi tu n'auras pas de réponse complète et pertinente à ta question. Je voulais faire principalement deux choses (en ce moment), en dehors
de progresser en programmation (ce qui, par expérience, ne se fait qu'en programmant) : un administrateur d'IA pour un jeu, et des algorithmes d'optimisation (toutes les méthodes utilisées en math.app., du data minig AG-réseaux de neurones jusqu'à des méthodes systématiques de recherche opérationnelle). Pour clarifier la première partie, l'idée est de créer un programme qui reçoit le code de sous-classes de la classe abstraite IA, et qui les fait jouer les unes contre les autres pour les comparer. Bien sûr, de pair à ce projet, il y a la programmation d'une de ces IA. Endymion
Christophe Lephay
"Gabriel Dos Reis" a écrit dans le message de news:
"Christophe Lephay" writes:
[...]
| Je crois que ce n'est pas demain la veille que C++ intègrera une GUI. C'est
| lié, de mon point de vue, au positionnement de C++ en ce qui concerne | l'efficacité : standardiser quelque chose qui dépend autant de | l'environnement ne peut se faire que par un nivellement par le bas (tant sur
| le plan des performances que du nombre de fonctionnalités).
Ce n'est pas mon opinion. L'exemple de la STL n'est pas vraiment ce que j'appelle un nivellement par le bas.
Mais la SL me parait bien moins dépendant de l'environnement qu'une interface graphique...
Je ne dis pas que toute standardisation ou normalisation implique un nivellement vers le bas, mais que quand on a affaire à trop de spécificités, particulièrement complexes qui plus est, la standardisation est un nivellement par le bas, qui n'est pas suivi avec ferveur, du reste, par les principaux acteurs du marché.
Chris
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message de
news:m34r15x4yh.fsf@uniton.integrable-solutions.net...
| Je crois que ce n'est pas demain la veille que C++ intègrera une GUI.
C'est
| lié, de mon point de vue, au positionnement de C++ en ce qui concerne
| l'efficacité : standardiser quelque chose qui dépend autant de
| l'environnement ne peut se faire que par un nivellement par le bas (tant
sur
| le plan des performances que du nombre de fonctionnalités).
Ce n'est pas mon opinion. L'exemple de la STL n'est pas vraiment ce
que j'appelle un nivellement par le bas.
Mais la SL me parait bien moins dépendant de l'environnement qu'une
interface graphique...
Je ne dis pas que toute standardisation ou normalisation implique un
nivellement vers le bas, mais que quand on a affaire à trop de spécificités,
particulièrement complexes qui plus est, la standardisation est un
nivellement par le bas, qui n'est pas suivi avec ferveur, du reste, par les
principaux acteurs du marché.
"Gabriel Dos Reis" a écrit dans le message de news:
"Christophe Lephay" writes:
[...]
| Je crois que ce n'est pas demain la veille que C++ intègrera une GUI. C'est
| lié, de mon point de vue, au positionnement de C++ en ce qui concerne | l'efficacité : standardiser quelque chose qui dépend autant de | l'environnement ne peut se faire que par un nivellement par le bas (tant sur
| le plan des performances que du nombre de fonctionnalités).
Ce n'est pas mon opinion. L'exemple de la STL n'est pas vraiment ce que j'appelle un nivellement par le bas.
Mais la SL me parait bien moins dépendant de l'environnement qu'une interface graphique...
Je ne dis pas que toute standardisation ou normalisation implique un nivellement vers le bas, mais que quand on a affaire à trop de spécificités, particulièrement complexes qui plus est, la standardisation est un nivellement par le bas, qui n'est pas suivi avec ferveur, du reste, par les principaux acteurs du marché.
Chris
Christophe Lephay
"Endymion" a écrit dans le message de news:
Est-ce qu'on peut dire que définir une classe abstraite avec quelques méthodes abstraites et quelques champs et demader aux programmeurs d'écrire des sous-classes de cette classe abstraite, c'est de la programmation par contrat ?
Non.
chris
"Endymion" <pr.nm@laposte.net> a écrit dans le message de
news:4219ae8a.0307282155.5b57c3d8@posting.google.com...
Est-ce qu'on peut dire que définir une classe abstraite avec quelques
méthodes abstraites et quelques champs et demader aux programmeurs
d'écrire des sous-classes de cette classe abstraite, c'est de la
programmation par contrat ?
Est-ce qu'on peut dire que définir une classe abstraite avec quelques méthodes abstraites et quelques champs et demader aux programmeurs d'écrire des sous-classes de cette classe abstraite, c'est de la programmation par contrat ?
Non.
chris
vclassine
"Arnaud Debaene" wrote in message news:<3f2584ab$0$1879$...
Vincent wrote:
Je suppose que la programmation par contrat consiste à créer une classe abstraite avec des méthodes abstraites, ce qui force tous ceux qui doivent créer des sous-classes de cette classe à définir un certain nombre de méthodes. Pas exactement l'idée c'est plutôt de s'assurer que le contrat de
chaque méthode soit respecter, par exemple qu'un argument de la fonction n'est pas nul, ou que l'appel de telle fonction n'est effectuée que dans une état donné de l'objet.
Mais là encore je ne suis pas tout à fait d'accord avec Kanze en fait java permet tout à fait ce genre de chose. Pour les arguments et pour une autre discussion sur C++ et Java (a propos de la qualité) voir le fil "Pour ou contre un code 100% objet" sur fr.comp.objet.
Et comment u fais en Java pour faire une classe qui "implémenteé deux interfaces au snes donné par James (c'est-à-dire avec pre-conditions et post-conditions) ? Sans héritage multiple d'implémentation, je ne vois pas comment on pourrait s'en sortir.
Je comprend ce que tu veux dire, mais en fait en java la question se pose différemment. Tu ne peux pas hérité de deux classe, donc pas de deux classe "avec contrat". Quand tu hérites d'une classe tu as tous les outils pour éviter la rupture du contrat. Si tu veux récupèrer l'interface et le comportement de deux classes, tu dois: - implémenter les deux interfaces. Ou une seule si tu hérites de l'autre. Ou implémenter une interface qui hériterait des deux autres... - composer les deux classes portant le comportement, ou une seule si tu hérit de l'autre, éventuellement en les dérivant. - "brancher" les interfaces avec les classes membres.
Concrètement c'est chiant à écrire, mais ça ne pose pas de problème de rupture de contrat. Et bien sûr ça n'est qu'une simulation d'héritage multiple...
"Arnaud Debaene" <adebaene@club-internet.fr> wrote in message news:<3f2584ab$0$1879$626a54ce@news.free.fr>...
Vincent wrote:
Je suppose que la programmation par contrat consiste à créer une
classe abstraite avec des méthodes abstraites, ce qui force tous ceux
qui doivent créer des sous-classes de cette classe à définir un
certain nombre de méthodes.
Pas exactement l'idée c'est plutôt de s'assurer que le contrat de
chaque méthode soit respecter, par exemple qu'un argument de la
fonction n'est pas nul, ou que l'appel de telle fonction n'est
effectuée que dans une état donné de l'objet.
Mais là encore je ne suis pas tout à fait d'accord avec Kanze en fait
java permet tout à fait ce genre de chose. Pour les arguments et pour
une autre discussion sur C++ et Java (a propos de la qualité) voir le
fil "Pour ou contre un code 100% objet" sur fr.comp.objet.
Et comment u fais en Java pour faire une classe qui "implémenteé deux
interfaces au snes donné par James (c'est-à-dire avec pre-conditions et
post-conditions) ? Sans héritage multiple d'implémentation, je ne vois pas
comment on pourrait s'en sortir.
Je comprend ce que tu veux dire, mais en fait en java la question se
pose différemment. Tu ne peux pas hérité de deux classe, donc pas de
deux classe "avec contrat". Quand tu hérites d'une classe tu as tous
les outils pour éviter la rupture du contrat. Si tu veux récupèrer
l'interface et le comportement de deux classes, tu dois:
- implémenter les deux interfaces. Ou une seule si tu hérites de
l'autre. Ou implémenter une interface qui hériterait des deux
autres...
- composer les deux classes portant le comportement, ou une seule
si tu hérit de l'autre, éventuellement en les dérivant.
- "brancher" les interfaces avec les classes membres.
Concrètement c'est chiant à écrire, mais ça ne pose pas de problème de
rupture de contrat. Et bien sûr ça n'est qu'une simulation d'héritage
multiple...
"Arnaud Debaene" wrote in message news:<3f2584ab$0$1879$...
Vincent wrote:
Je suppose que la programmation par contrat consiste à créer une classe abstraite avec des méthodes abstraites, ce qui force tous ceux qui doivent créer des sous-classes de cette classe à définir un certain nombre de méthodes. Pas exactement l'idée c'est plutôt de s'assurer que le contrat de
chaque méthode soit respecter, par exemple qu'un argument de la fonction n'est pas nul, ou que l'appel de telle fonction n'est effectuée que dans une état donné de l'objet.
Mais là encore je ne suis pas tout à fait d'accord avec Kanze en fait java permet tout à fait ce genre de chose. Pour les arguments et pour une autre discussion sur C++ et Java (a propos de la qualité) voir le fil "Pour ou contre un code 100% objet" sur fr.comp.objet.
Et comment u fais en Java pour faire une classe qui "implémenteé deux interfaces au snes donné par James (c'est-à-dire avec pre-conditions et post-conditions) ? Sans héritage multiple d'implémentation, je ne vois pas comment on pourrait s'en sortir.
Je comprend ce que tu veux dire, mais en fait en java la question se pose différemment. Tu ne peux pas hérité de deux classe, donc pas de deux classe "avec contrat". Quand tu hérites d'une classe tu as tous les outils pour éviter la rupture du contrat. Si tu veux récupèrer l'interface et le comportement de deux classes, tu dois: - implémenter les deux interfaces. Ou une seule si tu hérites de l'autre. Ou implémenter une interface qui hériterait des deux autres... - composer les deux classes portant le comportement, ou une seule si tu hérit de l'autre, éventuellement en les dérivant. - "brancher" les interfaces avec les classes membres.
Concrètement c'est chiant à écrire, mais ça ne pose pas de problème de rupture de contrat. Et bien sûr ça n'est qu'une simulation d'héritage multiple...
vclassine
Julien Blanc wrote in message news:<3f25236d$0$1913$...
[surcharge d'opérateurs]
Comme tu le dis c'est à double tranchant, et ça n'est qu'une fonctionnalité syntaxique qui en tout état de cause n'est pas souvent vraiment utile.
c'est plus qu'une simple "fonctionnalité syntaxique". Je fais un code avec des entiers, je m'aperçois que le type ne me convient pas et que je suis obligé d'utiliser une classe entiers_bornés. La surcharge d'opérateurs m'évite de réécrire tout mon code. Tu peux me fournir un bout de code?
Sans parler du fait que + est standard et sa signification évidente, alors que add peut devenir plus si je programme en français, et je ne parle même pas des autres langues... ça c'est sûr, mais notes que le problème des fonctions remplacables
par des opérateurs ne sont qu'une goutte d'eau dans la mer des fonctions...
Là encore c'est une commodité syntaxique (qui sera incluse dans la 1.5) rien n'empêche d'écrire une version de chaque conteneur par type, c'est lourd mais ça se fait.
je suis distributeur, je vends une classe conteneur. En java, je ne peux pas (du moins, mon conteneur sera un conteneur de Object ce qui est loin d'être satisfaisant dans beaucoup de cas, vu le nombre de cast que cela est capable d'engendrer). C'est beaucoup plus qu'une commodité syntaxique (sans parler de généricité contrainte, certes non-encore gérée par c++) Je rappel que ça arrive, et que ça manquait.
Mais il n'empêche que l'utilisateur peut contraindre le type du conteneur en dérivant la classe. Mais effectivement la possibilité de le gèrer n'est pas offerte au fournisseur de conteneur. Bien sûr c'est utile, je dis juste que ça n'est pas indispensable...
déjà, il manque les invariants ;). M'en fout personne ne peut hériter d'une classe dans un newsgroup!!!
:-)
Ensuite, quelqu'un qui implémente une nouvelle fonctionnalité dans une classe fille pourra faire un appel direct à faire_vraiment_truc(). Euh? En C++ on peut écrire une fonction redéfinissable mais pas
appelable par la classe fille?
Je crois que c'est ce que James voulait dire par /c'est extrèmement difficile à forcer que tous les appels de la fonction passent par une fonction non-virtuelle/. Tu peux fournir le mécanisme, mais pas obliger son utilisation. Là il va me falloir l'équivalent C++ pour comprendre...
du reste, je n'ai jamais trouvé cet argument particulièrement pertinent. C'est à l'environnement de développement d'être capable, à partir d'un fichier source, de fournir l'interface. De ce côté-là, javadoc est plutôt performant. Je ne sais pas si la remarque initiale conceranait l'aspect
documentaire, il est vrai que dans ce cas javadoc est la réponse.
Julien Blanc <Julien.Blanc@imag.fr> wrote in message news:<3f25236d$0$1913$626a54ce@news.free.fr>...
[surcharge d'opérateurs]
Comme tu le dis c'est à double tranchant, et ça n'est qu'une
fonctionnalité syntaxique qui en tout état de cause n'est pas souvent
vraiment utile.
c'est plus qu'une simple "fonctionnalité syntaxique". Je fais un code
avec des entiers, je m'aperçois que le type ne me convient pas et que je
suis obligé d'utiliser une classe entiers_bornés. La surcharge
d'opérateurs m'évite de réécrire tout mon code.
Tu peux me fournir un bout de code?
Sans parler du fait que
+ est standard et sa signification évidente, alors que add peut devenir
plus si je programme en français, et je ne parle même pas des autres
langues...
ça c'est sûr, mais notes que le problème des fonctions remplacables
par des opérateurs ne sont qu'une goutte d'eau dans la mer des
fonctions...
Là encore c'est une commodité syntaxique (qui sera incluse dans la
1.5) rien n'empêche d'écrire une version de chaque conteneur par type,
c'est lourd mais ça se fait.
je suis distributeur, je vends une classe conteneur. En java, je ne peux
pas (du moins, mon conteneur sera un conteneur de Object ce qui est loin
d'être satisfaisant dans beaucoup de cas, vu le nombre de cast que cela
est capable d'engendrer). C'est beaucoup plus qu'une commodité
syntaxique (sans parler de généricité contrainte, certes non-encore
gérée par c++)
Je rappel que ça arrive, et que ça manquait.
Mais il n'empêche que l'utilisateur peut contraindre le type du
conteneur en dérivant la classe. Mais effectivement la possibilité de
le gèrer n'est pas offerte au fournisseur de conteneur. Bien sûr c'est
utile, je dis juste que ça n'est pas indispensable...
déjà, il manque les invariants ;).
M'en fout personne ne peut hériter d'une classe dans un newsgroup!!!
:-)
Ensuite, quelqu'un qui implémente une
nouvelle fonctionnalité dans une classe fille pourra faire un appel
direct à faire_vraiment_truc().
Euh? En C++ on peut écrire une fonction redéfinissable mais pas
appelable par la classe fille?
Je crois que c'est ce que James voulait
dire par /c'est extrèmement difficile à forcer que tous les appels de la
fonction passent par une fonction non-virtuelle/. Tu peux fournir le
mécanisme, mais pas obliger son utilisation.
Là il va me falloir l'équivalent C++ pour comprendre...
du reste, je n'ai jamais trouvé cet argument particulièrement pertinent.
C'est à l'environnement de développement d'être capable, à partir d'un
fichier source, de fournir l'interface. De ce côté-là, javadoc est
plutôt performant.
Je ne sais pas si la remarque initiale conceranait l'aspect
documentaire, il est vrai que dans ce cas javadoc est la réponse.
Julien Blanc wrote in message news:<3f25236d$0$1913$...
[surcharge d'opérateurs]
Comme tu le dis c'est à double tranchant, et ça n'est qu'une fonctionnalité syntaxique qui en tout état de cause n'est pas souvent vraiment utile.
c'est plus qu'une simple "fonctionnalité syntaxique". Je fais un code avec des entiers, je m'aperçois que le type ne me convient pas et que je suis obligé d'utiliser une classe entiers_bornés. La surcharge d'opérateurs m'évite de réécrire tout mon code. Tu peux me fournir un bout de code?
Sans parler du fait que + est standard et sa signification évidente, alors que add peut devenir plus si je programme en français, et je ne parle même pas des autres langues... ça c'est sûr, mais notes que le problème des fonctions remplacables
par des opérateurs ne sont qu'une goutte d'eau dans la mer des fonctions...
Là encore c'est une commodité syntaxique (qui sera incluse dans la 1.5) rien n'empêche d'écrire une version de chaque conteneur par type, c'est lourd mais ça se fait.
je suis distributeur, je vends une classe conteneur. En java, je ne peux pas (du moins, mon conteneur sera un conteneur de Object ce qui est loin d'être satisfaisant dans beaucoup de cas, vu le nombre de cast que cela est capable d'engendrer). C'est beaucoup plus qu'une commodité syntaxique (sans parler de généricité contrainte, certes non-encore gérée par c++) Je rappel que ça arrive, et que ça manquait.
Mais il n'empêche que l'utilisateur peut contraindre le type du conteneur en dérivant la classe. Mais effectivement la possibilité de le gèrer n'est pas offerte au fournisseur de conteneur. Bien sûr c'est utile, je dis juste que ça n'est pas indispensable...
déjà, il manque les invariants ;). M'en fout personne ne peut hériter d'une classe dans un newsgroup!!!
:-)
Ensuite, quelqu'un qui implémente une nouvelle fonctionnalité dans une classe fille pourra faire un appel direct à faire_vraiment_truc(). Euh? En C++ on peut écrire une fonction redéfinissable mais pas
appelable par la classe fille?
Je crois que c'est ce que James voulait dire par /c'est extrèmement difficile à forcer que tous les appels de la fonction passent par une fonction non-virtuelle/. Tu peux fournir le mécanisme, mais pas obliger son utilisation. Là il va me falloir l'équivalent C++ pour comprendre...
du reste, je n'ai jamais trouvé cet argument particulièrement pertinent. C'est à l'environnement de développement d'être capable, à partir d'un fichier source, de fournir l'interface. De ce côté-là, javadoc est plutôt performant. Je ne sais pas si la remarque initiale conceranait l'aspect
documentaire, il est vrai que dans ce cas javadoc est la réponse.
vclassine
Arf! Si tu considères que les templates sont une "commodité syntaxique", Expression un peu mal choisie je te l'accorde, ça ne rend pas bien
compte de l'utilité de la chose... Mais je continue de penser que ça n'est pas indispensable.
je te recommande chaudement la lecture de "Modern C++ Design", ou bien de te pencher sur le design de certaines librairies (Boost, ATL, Blitz,....). Les templates ne servent pas qu'à faire des conteneurs de T, loin de là. Oui, mais quoi qu'il arrive ça ne fait que remplacer le <template> par
le vrai type, non? D'où l'idée de "commodité syntaxique"...
Arf! Si tu considères que les templates sont une "commodité syntaxique",
Expression un peu mal choisie je te l'accorde, ça ne rend pas bien
compte de l'utilité de la chose... Mais je continue de penser que ça
n'est pas indispensable.
je
te recommande chaudement la lecture de "Modern C++ Design", ou bien de te
pencher sur le design de certaines librairies (Boost, ATL, Blitz,....). Les
templates ne servent pas qu'à faire des conteneurs de T, loin de là.
Oui, mais quoi qu'il arrive ça ne fait que remplacer le <template> par
le vrai type, non? D'où l'idée de "commodité syntaxique"...
Arf! Si tu considères que les templates sont une "commodité syntaxique", Expression un peu mal choisie je te l'accorde, ça ne rend pas bien
compte de l'utilité de la chose... Mais je continue de penser que ça n'est pas indispensable.
je te recommande chaudement la lecture de "Modern C++ Design", ou bien de te pencher sur le design de certaines librairies (Boost, ATL, Blitz,....). Les templates ne servent pas qu'à faire des conteneurs de T, loin de là. Oui, mais quoi qu'il arrive ça ne fait que remplacer le <template> par
le vrai type, non? D'où l'idée de "commodité syntaxique"...
