Constructor et vector par defaut

Olivier Azeau <john@doe.com> writes:

Si l'intention de l'utilisateur est de passer zéro paramètres, autant le
forcer à la faire explicitement et non pas le laisser compter sur
l'utilisation d'un paramètre par défaut qui pourra évoluer.

Pourquoi ?

--drkm

Vladimir Votiakov wrote:

Pas accord.

Pas d'accord avec quel partie de mon message ?

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é ?

Pour moi C++ égal efficacité (pas à tout prix bien sur).

Tiens, pour moi, C++ se serait surtout robustesse,
puis ensuite le meilleur compromis efficacité/portabilité.

Regardez QT 4.0, par exemple,
une des nouveautés c'est grand coup de balai sur le code inutile
(en terme de cpu justement) et en startup surtout.

Le code raisonnable pour moi :

T(): unAttribut(0), unAutre(0) {}

et

T(int i): unAttribut(i), unAutre(0) {}

et autre

T(int i, const std::vector<double>& v)
{
// blah-blah
}

Y a pas grand chose à documenter ici.

On a peut-être pas les même hypothèses, mais je pensais
1) que dans de nombreuses conventions de programmation, on
imposait de documenter toutes les fonctions
2) qu'il y avait une fonction init, qui n'était pas un
constructeur, dont j'ai soulevé les problèmes de perf
induits
3) qu'on optimisait "après" avoir décellé un problème
de perf

Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.

drkm wrote:

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

Vladimir Votiakov wrote:

J'ai envie d'appeler ce genre de code de l'abus de intelligence
de compilateur.

Non, on transfère du coût de développement sur du coût CPU.

Et même, je ne suis vraiment pas sûr d'un tel impact sur le temps
d'exécution. Ce que proposait Vladimir, si je me souviens bien, est
quelque chose comme :

ctor() {
vector<T> v ;
init( v ) ;
}

ctor( vector<T> const & v ) {
init( v ) ;
}

void init( vector<T> const & v ) {
}

vs. :

ctor( vector<T> const & v = vector<T>() ) {
}

Je ne vois pas d'impact clair sur le CPU.

D'autant que le v dans ctor() est lui aussi construit sur
la pile et détruit après usage, ce que je n'avais pas vu
au début.
On y ajoute ma remarque sur la construction des membres
de la classe, et on doit arriver à dire que la version
avec argument par défaut est plus rapide.

Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.

Olivier Azeau <john@doe.com> writes:

drkm wrote:

Olivier Azeau <john@doe.com> writes:

Si l'intention de l'utilisateur est de passer zéro paramètres,
autant le forcer à la faire explicitement et non pas le laisser
compter sur l'utilisation d'un paramètre par défaut qui pourra
évoluer.

Pourquoi ?

Parce que, de mon point de vue, les paramètres par défaut doivent faire
partie de l'implémentation, pas de l'interface.

Cela dépend. Surtout dans un cas comme celui-ci, où l'on a un
vecteur et la valeur par défaut est le vecteur vide.

Donc tu trouves que cela est un détail d'implementation, mais pas le
fait de déclarer une fonction avec le paramètre, et une seconde sans,
en définissant la sémantique de la seconde comme étant celle de la
première à laquelle on aurait passé un vecteur vide ?

A mon sens ils ne sont dans l'interface de la classe que pour des
raisons de compilation (tout comme les membres "private")

Mais si on décide de les mettre dans l'interface, j'espère que l'on
ne le fait pas par hasard.

Je trouve plus sain de programmer en disant qu'un paramètre par défaut
est là pour donner un comportement "par défaut" à une méthode, et ce,
quel que soit ce comportement : ce n'est pas à l'utilisateur de la
méthode d'aller regarder ce comportement pour tirer parti d'un
quelconque raccourci d'écriture.

Ben il doit lire la doc et savoir comment utiliser les fonctions et
classes qu'il utilise. Si tu déclares une fonction supplémentaire ne
prenant pas l'argument ayant une valeur par défaut (et dont
l'implémentation consiste à simuler cette valeur par défaut),
l'utilisateur doit de toute manière en apprendre la sémantique.

Qu'il doive apprendre à utiliser une fonction supplémentaire ou la
signification de l'utilisation de la valeur par défaut d'un paramètre,
je vois pas trop de différence.

Si celui qui utilise la méthode veut *explicitement* un comportement
alors il doit le spécifier.

Ne pas spécifier le paramètre ayant une valeur par défaut n'est pas
*explicite* ?

Il est trop dangereux de laisser faire la
valeur par défaut car si, dans le futur, elle change, on perdra le
comportement souhaité.

Mais si le comportement doit changer, ben il doit changer. Dans un
cas comme dans l'autre. L'argument que je vois ici, serait de
supprimer le besoin de recompiler. Mais ce n'est pas _forcément_ un
argument de poids.

--drkm

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:

D'autant que le v dans ctor() est lui aussi construit sur
la pile et détruit après usage, ce que je n'avais pas vu
au début.

On peut faire différemment. Mais évidemment, on peut alors faire
différemment dans les deux cas :

class A {
public:
A() {
init( ourDefaultVector ) ;
}
A( vector<T> const & v ) {
init( v ) ;
}
void init( vector<T> const & v ) {
}
private:
static vector<T> ourDefaultVector ;
} ;

vs. :

class A {
public:
A( vector<T> const & v = ourDefaultVector ) {
}
private:
static vector<T> ourDefaultVector ;
} ;

--drkm

Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:

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.

Je ne me souviens pas avoir jamais entendu cette règle. Pas mal.
Je dirais qu'il s'agit d'un critère suffisant pour exclure la valeur
par défaut. Mais pas nécessaire.

--drkm

Olivier Azeau <john@doe.com> writes:

drkm wrote:

Olivier Azeau <john@doe.com> writes:

A mon sens ils ne sont dans l'interface de la classe que pour des
raisons de compilation (tout comme les membres "private")

Mais si on décide de les mettre dans l'interface, j'espère que
l'on ne le fait pas par hasard.

Ce n'est pas une question de hasard : on n'a tout simplement pas le
choix car le compilo utilise cette info pour générer le code de l'appel.

Et alors ? Tu le sais. Donc si tu décides de placer une valeur par
défaut pour un de tes paramètres, tu le fais en connaissance de cause.
Je ne vois pas le problème.

[...]

Ce que je veux dire c'est que les seuls paramètres par défaut valables
sont ceux que l'on peut vouloir changer occasionellement pour obtenir un
comportement particulier, pas ceux qui ne vont qu'être un raccourci
d'écriture d'un cas usuel.

Quelle est la différence ?

--drkm

Olivier Azeau <john@doe.com> writes:

drkm wrote:

Olivier Azeau <john@doe.com> writes:

Ce que je veux dire c'est que les seuls paramètres par défaut
valables sont ceux que l'on peut vouloir changer occasionellement
pour obtenir un comportement particulier, pas ceux qui ne vont
qu'être un raccourci d'écriture d'un cas usuel.

Quelle est la différence ?

La partie de mon message que tu as tronquée :

[...]

Mais ça n'a rien à voir. Ou je n'ai rien compris. Je comprend de
ton analogie qu'il y a des paramètres que l'on veut obliger
l'utilisateur à spécifier. Nous parlons ici de la différence entre
une valeur par défaut et une surcharge avec un paramètre en moins.

Si l'on souhaite obliger l'utilisateur à spécifier une valeur, ce
problème de choix ne se pose pas.

--drkm

Olivier Azeau <john@doe.com> writes:

En fait, on ne parle pas de la même chose :-(
Quelque messages plus haut dans cette branche du thread, j'avais
commencé à critiquer l'utilisation du paramètre par défaut en tant que
commodité d'écriture, ce qui est pour moi de l'obfuscation.
Et cela est bien sur tout aussi vrai dans le cas d'une surcharge avec un
paramètre en moins qui, dans le cas d'une utilisation comme commodité
d'écriture par l'appelant va, de la même manière, amener à du code tout
aussi illisible.

Donc, tout cela pour dire : « lorsque l'on veut que l'utilisateur
fournisse une valeur, ne pas permettre qu'il ne la fournisse pas (par
valeur par défaut ou par surcharge) » ? Ok.

--drkm

Olivier Azeau wrote:

drkm wrote:

Olivier Azeau <john@doe.com> writes:

Si l'intention de l'utilisateur est de passer zéro
paramètres, autant le forcer à la faire explicitement et non
pas le laisser compter sur l'utilisation d'un paramètre par
défaut qui pourra évoluer.

Pourquoi ?

Parce que, de mon point de vue, les paramètres par défaut
doivent faire partie de l'implémentation, pas de l'interface.

Il y a une différence. Fournir un paramètre par défaut, c'est
effectivement fournir deux fonctions. À la différence près que
je n'ai qu'à documenter une fonction, et que l'utilisateur n'a
qu'à lire la documentation d'une fonction. Si la documentation
de la fonction avec le paramètre en moins se résume à :
effectue "f( ..., defaultParameter )"
alors, je trouve que fournir deux fonctions, à la place
d'utiliser un paramètre par défaut, c'est une légère
obfuscation.

--
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