j'ai une classe dont les objets peuvent etre construits en specifiant ou
non le dernier parametre qui est un std::vector. J'avais donc simplement
utilise un parametre par defaut qui mettait le vector vide s'il n'etait
pas initialise. Mais dernierement, on me dit (avec des explications
fumeuses que je n'ai pas comprises...) qu'il fallait pas faire ca. Je me
retrouve donc a faire 2 constructeurs appelant une fonction init. Celui
qui n'a pas le parametre associe au vector le cree simplement (vide) et
appelle la fonction init. Je trouve ca plus que douteux comme solution.
Alors pourquoi la premiere solution n'etait pas correcte?
Si on veut du développement simplifié on n'utilise pas ce genre de langage (il faut aller vers java).
J'ai parlé de développement simplifié ?
En fait, je vois surtout deux raisons pour préférer le C++ au Java : le rendement des développeurs est plus élevé, et le résultat est plus robuste. (Mais il faut mettre le premier en contexte. Si tu écris un GUI, et les alternatifs sont Java/Swing ou C++/X-Windows natif, le rendement des développeurs seraient bien plus élevé en Java, et la seule justification du C++ serait la robustité.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Marc Boyer wrote:
Vladimir Votiakov wrote:
[...]
Si on veut du développement simplifié on n'utilise pas
ce genre de langage (il faut aller vers java).
J'ai parlé de développement simplifié ?
En fait, je vois surtout deux raisons pour préférer le C++ au
Java : le rendement des développeurs est plus élevé, et le
résultat est plus robuste. (Mais il faut mettre le premier en
contexte. Si tu écris un GUI, et les alternatifs sont Java/Swing
ou C++/X-Windows natif, le rendement des développeurs seraient
bien plus élevé en Java, et la seule justification du C++ serait
la robustité.)
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Si on veut du développement simplifié on n'utilise pas ce genre de langage (il faut aller vers java).
J'ai parlé de développement simplifié ?
En fait, je vois surtout deux raisons pour préférer le C++ au Java : le rendement des développeurs est plus élevé, et le résultat est plus robuste. (Mais il faut mettre le premier en contexte. Si tu écris un GUI, et les alternatifs sont Java/Swing ou C++/X-Windows natif, le rendement des développeurs seraient bien plus élevé en Java, et la seule justification du C++ serait la robustité.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Loïc Joly wrote:
drkm wrote:
[Argument par défaut ou surcharge]
J'avais lu une fois un critère que je toruve pas mal pour choisir :
On réfléchit à l'implémentation si on met un argument par défaut. Si elle doit gérer de manière spécifique le cas ou l'argument aurait sa valeur par défaut, mieux vaut 2 fonctions.
Personnellement, je dirais qu'on reflechit à la documentation. Si la documentation de la deuxième fonction se résume à : effectue f( premierParametre, defaut ) on utilise un paramètre par défaut. Sinon, on utilise deux fonctions.
Note bien que dans le cas des pointeurs, il y a souvent le test quand même. Parce que la valeur par défaut est souvent NULL, mais qu'il faut traiter (et documenter) le cas où l'utilisateur passe NULL quand même. Dans ces cas-là, on pourrait évidemment se poser la question s'il ne vaut pas mieux une fonction qui prend une référence, et une autre sans le paramètre, mais la réponse dépend de la classe.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly wrote:
drkm wrote:
[Argument par défaut ou surcharge]
J'avais lu une fois un critère que je toruve pas mal pour choisir :
On réfléchit à l'implémentation si on met un argument par
défaut. Si elle doit gérer de manière spécifique le cas ou
l'argument aurait sa valeur par défaut, mieux vaut 2
fonctions.
Personnellement, je dirais qu'on reflechit à la documentation.
Si la documentation de la deuxième fonction se résume à :
effectue f( premierParametre, defaut )
on utilise un paramètre par défaut. Sinon, on utilise deux
fonctions.
Note bien que dans le cas des pointeurs, il y a souvent le test
quand même. Parce que la valeur par défaut est souvent NULL,
mais qu'il faut traiter (et documenter) le cas où l'utilisateur
passe NULL quand même. Dans ces cas-là, on pourrait évidemment
se poser la question s'il ne vaut pas mieux une fonction qui
prend une référence, et une autre sans le paramètre, mais la
réponse dépend de la classe.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
J'avais lu une fois un critère que je toruve pas mal pour choisir :
On réfléchit à l'implémentation si on met un argument par défaut. Si elle doit gérer de manière spécifique le cas ou l'argument aurait sa valeur par défaut, mieux vaut 2 fonctions.
Personnellement, je dirais qu'on reflechit à la documentation. Si la documentation de la deuxième fonction se résume à : effectue f( premierParametre, defaut ) on utilise un paramètre par défaut. Sinon, on utilise deux fonctions.
Note bien que dans le cas des pointeurs, il y a souvent le test quand même. Parce que la valeur par défaut est souvent NULL, mais qu'il faut traiter (et documenter) le cas où l'utilisateur passe NULL quand même. Dans ces cas-là, on pourrait évidemment se poser la question s'il ne vaut pas mieux une fonction qui prend une référence, et une autre sans le paramètre, mais la réponse dépend de la classe.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
