j'ai programmé actuellement essenssiellement en C pour des DSP ,
microcontroleur etc..
J'ai un nouveau projet qui va bientot démarré sur une prateforme PC (
Windows XP ou Linux non choisi actuellement )
Ne connaissant pas Java et certaines personnes me le conseillant , j'aimerai
savoir quels sont les avantages de l'un par rapport à l'autre
"Mickael Pointier" wrote in message news:<bmo7hd$dhr$...
Ceci dit, je crois que la syntaxe Java est en fait mieux ici. Ou au moins, pourait l'être : le problème, c'est dans des expressions du genre :
int i = table[ "toto" ] ;
La sémantique ici n'est pas claire ; les map STL (et les hash_map proposés) font une insertion automatique avec une valeur par défaut. Du coup, tu ne peux pas le faire sur une table const.
En Java, tu n'as pas la syntaxe avec [].
Ce que je considère, dans ce cas-ci, un avantage:-).
Ah bon. Alors là évidemment... Mais je trouve la sémantique de cette syntaxe est, au contraire, tout à fait conforme à l'idée que je me fais d'une table associative utile.
J'abonde dans ton sens.
Autant je n'aime pas les .first et .second (pas intuitif pour un sous), autant la syntaxe avec crochets me parait évidemment comprénsible.
Mais avec quelle sémantique ? Si on rapporte à des tableaux classiques, indicer avec une indice qui n'existe pas est un comportement indéfini. Est-ce donc l'existance d'un élément avec la clé une précondition de l'opérateur ?
Tant les crochets me paraît aussi compréhensible, tant je m'attends aussi à pouvoir m'en servir sur un map const.
Ce qui l'est moins c'est que ca crée automatiquement l'élément s'il n'existe pas...
C'est effectivement le problème.
mais bon, je suppose que ca ne doit pas être évident de distinguer la lecture et l'écriture.
C'est en fait assez facile -- je le fais dans d'autres classes.
Mais là n'est pas le problème -- du moment qu'on peut accéder à des éléments qui n'y sont pas encore, il faut poser la question si l'opérateur surchargé convient. (En C++, évidemment -- en AWK, la question ne se pose pas, puisque la taille de tout tableau est dynamique.)
Il y a aussi le problème que du coup, il te faut un constructeur par défaut.
Si l'opérateur [] avait réelement comme précondition que l'élément existait, je pourrais éventuellement l'accepter. Bien que franchement, je n'ai pas de problème avec get et set non plus.
-- 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
"Mickael Pointier" <mpointie@eden-studios.fr> wrote in message
news:<bmo7hd$dhr$1@reader1.imaginet.fr>...
Ceci dit, je crois que la syntaxe Java est en fait mieux ici. Ou
au moins, pourait l'être : le problème, c'est dans des
expressions du genre :
int i = table[ "toto" ] ;
La sémantique ici n'est pas claire ; les map STL (et les hash_map
proposés) font une insertion automatique avec une valeur par
défaut. Du coup, tu ne peux pas le faire sur une table const.
En Java, tu n'as pas la syntaxe avec [].
Ce que je considère, dans ce cas-ci, un avantage:-).
Ah bon. Alors là évidemment... Mais je trouve la sémantique de cette
syntaxe est, au contraire, tout à fait conforme à l'idée que je me
fais d'une table associative utile.
J'abonde dans ton sens.
Autant je n'aime pas les .first et .second (pas intuitif pour un
sous), autant la syntaxe avec crochets me parait évidemment
comprénsible.
Mais avec quelle sémantique ? Si on rapporte à des tableaux classiques,
indicer avec une indice qui n'existe pas est un comportement indéfini.
Est-ce donc l'existance d'un élément avec la clé une précondition de
l'opérateur ?
Tant les crochets me paraît aussi compréhensible, tant je m'attends
aussi à pouvoir m'en servir sur un map const.
Ce qui l'est moins c'est que ca crée automatiquement l'élément s'il
n'existe pas...
C'est effectivement le problème.
mais bon, je suppose que ca ne doit pas être évident de distinguer la
lecture et l'écriture.
C'est en fait assez facile -- je le fais dans d'autres classes.
Mais là n'est pas le problème -- du moment qu'on peut accéder à des
éléments qui n'y sont pas encore, il faut poser la question si
l'opérateur surchargé convient. (En C++, évidemment -- en AWK, la
question ne se pose pas, puisque la taille de tout tableau est
dynamique.)
Il y a aussi le problème que du coup, il te faut un constructeur par
défaut.
Si l'opérateur [] avait réelement comme précondition que l'élément
existait, je pourrais éventuellement l'accepter. Bien que franchement,
je n'ai pas de problème avec get et set non plus.
--
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
"Mickael Pointier" wrote in message news:<bmo7hd$dhr$...
Ceci dit, je crois que la syntaxe Java est en fait mieux ici. Ou au moins, pourait l'être : le problème, c'est dans des expressions du genre :
int i = table[ "toto" ] ;
La sémantique ici n'est pas claire ; les map STL (et les hash_map proposés) font une insertion automatique avec une valeur par défaut. Du coup, tu ne peux pas le faire sur une table const.
En Java, tu n'as pas la syntaxe avec [].
Ce que je considère, dans ce cas-ci, un avantage:-).
Ah bon. Alors là évidemment... Mais je trouve la sémantique de cette syntaxe est, au contraire, tout à fait conforme à l'idée que je me fais d'une table associative utile.
J'abonde dans ton sens.
Autant je n'aime pas les .first et .second (pas intuitif pour un sous), autant la syntaxe avec crochets me parait évidemment comprénsible.
Mais avec quelle sémantique ? Si on rapporte à des tableaux classiques, indicer avec une indice qui n'existe pas est un comportement indéfini. Est-ce donc l'existance d'un élément avec la clé une précondition de l'opérateur ?
Tant les crochets me paraît aussi compréhensible, tant je m'attends aussi à pouvoir m'en servir sur un map const.
Ce qui l'est moins c'est que ca crée automatiquement l'élément s'il n'existe pas...
C'est effectivement le problème.
mais bon, je suppose que ca ne doit pas être évident de distinguer la lecture et l'écriture.
C'est en fait assez facile -- je le fais dans d'autres classes.
Mais là n'est pas le problème -- du moment qu'on peut accéder à des éléments qui n'y sont pas encore, il faut poser la question si l'opérateur surchargé convient. (En C++, évidemment -- en AWK, la question ne se pose pas, puisque la taille de tout tableau est dynamique.)
Il y a aussi le problème que du coup, il te faut un constructeur par défaut.
Si l'opérateur [] avait réelement comme précondition que l'élément existait, je pourrais éventuellement l'accepter. Bien que franchement, je n'ai pas de problème avec get et set non plus.
-- 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
