Surchages ou valeurs par défaut?

Bonjour,

C'est une question que je me pose quelquefois, lorsque je code et que je me suis rappelé en lisant ceci: http://www.developpez.net/forums/d97...arge-fonction/

Prenons la fonction suivante:

Code:

---

1 2	int myHugeFunction(int myInt, double myDouble, bool myBool);

---

Je voulais savoir, qu'est ce qui est le mieux à faire entre la surcharges d'une fonction avec moins d'arguments:

Code:

---

1 2	int myHugeFunction(int myInt);

---

, ou mettre les variables de l'unique fonction avec des valeurs par défaut ( pour revenir donc au même ).

Code:

---

1 2	int myHugeFunction(int myInt, double myDouble=0.0, bool myBool=false);

---

Je sais que vous allez me répondre que, il y a des cas ou la fonction avec moins d'arguments, aura un code différent, mais je ne suis pas dans ce cas.

Donc ma question est: Qu'est ce qu'il y a de mieux à faire
Est ce qu'il y a une différence de cout ( compilation ? exécution ( je doute ) )

Merci pour la clarification :)

Personnellement, je n'aime pas les valeurs par défaut pour une raison majeur : Lors d'appel à boost::bind (ou autre), les arguments par défaut ne sont pas pris en compte. De plus, si on est habitué à utilisé une fonction avec un seul argument au lieu de 2, on peut croire que le type réel de la fonction est celui à un argument (car on l'a jamais utilisé avec 2). Du coup, on est obligé de chercher la doc de la fonction...
Vu le coup en temps d'un copier/coller, je préfère donc avoir 2 fonctions distinctes AVEC un commentaire disant que les 2 fonctions sont identiques.

Après, dans la majorité des cas, les arguments par défaut sont plus lisibles et rapides à faire. Il y a peut être un coup à la compilation (et encore) à avoir 2 différentes fonctions. En tout cas, aucune à l'exécution.

En espérant que cela t-aide.

Dans ton cas si les codes sont identiques, j'aurais tendance à préférer une seul fonction avec des paramètre par défaut, pour éviter la duplication de code.

Niveau perf, je dirais que 2 fonctions vont induire une taille d'executable plus grande, mais sans grandes conviction.

Bonjour,
Pour moi, la surcharge et la valeur par défaut sont deux choses différentes.
Je déteste écrire deux fois la même fonction (sauf pour un constructeur).
Donc si j'ai plusieurs fonctions qui font la même chose et retournent le même type de valeurs, j'aurais une fonction qui fait le travail et autant de fonctions avec des paramètres différents qui appelleront la première fonction.
Si par hasard, j'ai les mêmes type de paramètres, je rajoute un dernier paramètre (par exemple int type=0). Là il s'agit plus particulièrement d'une fonction pour laquelle je "pense" que j'aurai éventuellement l'occasion, plus tard, de lui rajouter d'autres types de traitement.
Quant à l'utilisation de la valeur par défaut (sauf cas précédent) je me limite normalement à des cas du genre (bool strict = false) ou (float tol=TOL). Signification, dans le cas général le ne traite pas la séquence "strict" ou la valeur tol est la tolérance par défaut.

Citation:

---

Envoyé par NoIdea

De plus, si on est habitué à utilisé une fonction avec un seul argument au lieu de 2, on peut croire que le type réel de la fonction est celui à un argument (car on l'a jamais utilisé avec 2). Du coup, on est obligé de chercher la doc de la fonction...

---

Je ne suis pas sur de bien comprendre l'argument que tu développes ici.

Que la fonction ait deux arguments dont l'un avec une valeur par défaut ou qu'il existe deux versions surchargées de la fonction (avec un et deux paramètres), le problème me semble le même.

Citation:

---

Envoyé par NoIdea

Vu le coup en temps d'un copier/coller, je préfère donc avoir 2 fonctions distinctes AVEC un commentaire disant que les 2 fonctions sont identiques.

---

Je ne pense pas que faire un simple copier/coller soit la meilleur chose à faire dans ce cas de figure.

Si pour une raison ou un autre tu ne peux pas utiliser de paramètres par défaut, plutôt que de copier/coller la fonction et avoir deux fonctions quasi-identique je préfère implémenter normalement la fonction la plus "générique" (ie celle avec le plus de paramètres) et implémenter les autres par un simple appel à celle-ci en valorisant les paramètres supplémentaire à la valeur qui convient.

Je suis totalement d'accord pour éviter des copié coller.
Dès que je peux, je implémente une fonction private qui fait le code commun, afin de ne l'écrire qu'une fois. ( C'est aussi possible pour les constructeur, et même que c'est mieux, normalement )

Sinon, si on ce penche sur un cas des constructeurs seulement, quel est le mieux la surcharge, ou la mise ne défaut des paramètres.

Concernant la surcharge des constructeurs, je préfère éviter l'appel d'un constructeur par un constructeur, parce que je ne sais pas exactement ce que fait un constructeur. Imaginons qu'un constructeur alloue de la mémoire à la classe dès l'appel, il y aura une fuite de mémoire. D'ailleurs je ne sais pas si c'est autorisé.
Par contre, rien n'empêche d'avoir dans chaque constructeur l'appel d'une fonction d'initialisation commune, c'est d'ailleurs pour moi la bonne méthode.
Concernant l'utilisation les paramètres avec valeur par défaut dans un constructeur, c'est tout à fait autorisé et logique, mais je ne l'utilise pas. S'il y a un constructeur par défaut et un constructeur avec un seul paramètre avec valeur par défaut, il y a ambiguïté.

Citation:

---

Envoyé par LittleWhite

Je sais que vous allez me répondre que, il y a des cas ou la fonction avec moins d'arguments, aura un code différent, mais je ne suis pas dans ce cas.

Donc ma question est: Qu'est ce qu'il y a de mieux à faire
Est ce qu'il y a une différence de cout ( compilation ? exécution ( je doute ) )

---

C'est mon argument : J'utilise toujours la fonction avec argument par défaut, sauf dans deux cas :
- J'ai besoin de plus de flexibilité que ce que m'apportent les arguments par défaut, genre f(int, int, string), que je veux pouvoir appeler f(int, int) ou f(int string)
- Je me retrouve dans le code de la fonction à tester si l'argument par défaut a ou pas sa valeur par défaut.

Citation:

---

Envoyé par Pierre Dolez

Concernant la surcharge des constructeurs, je préfère éviter l'appel d'un constructeur par un constructeur, parce que je ne sais pas exactement ce que fait un constructeur. Imaginons qu'un constructeur alloue de la mémoire à la classe dès l'appel, il y aura une fuite de mémoire. D'ailleurs je ne sais pas si c'est autorisé.

---

Ce n'est pas possible actuellement, et la syntaxe qui compile et qui ressemble à ça fait en fait autre chose.

Citation:

---

Envoyé par JolyLoic

C'est mon argument : J'utilise toujours la fonction avec argument par défaut, sauf dans deux cas :
- J'ai besoin de plus de flexibilité que ce que m'apportent les arguments par défaut, genre f(int, int, string), que je veux pouvoir appeler f(int, int) ou f(int string)
- Je me retrouve dans le code de la fonction à tester si l'argument par défaut a ou pas sa valeur par défaut.


Ce n'est pas possible actuellement, et la syntaxe qui compile et qui ressemble à ça fait en fait autre chose.

---

Je n'ai pas compris ces deux interventions.

Vous créez toujours des fonctions avec argument par défaut ? Plutôt que utiliser la surcharge de fonction ? C'est ça ? Autrement dit vous préférez la syntaxe des paramètres par défaut, pour faire une fonction qui pourrait utiliser la syntaxe de surcharge?


Ce qui n'est pas possible actuellement : l'appel d'un constructeur par un autre constructeur de la même classe ? C'est ça? Alors nous sommes d'accord.

Citation:

---

Envoyé par JolyLoic

C'est mon argument : J'utilise toujours la fonction avec argument par défaut, sauf dans deux cas

---

J'utilise de moins en moins:
- la raison deja donnee qu'on ne peut avoir des pointeurs vers des fonctions qui semblent exister mais qui en fait ont besoin de plus de parametres;
- en phase de maintenance, ajouter des parametres par defaut a une fonction qui existe, ca casse la compatibilite binaire. On se retrouve donc a utiliser des techniques differentes en phase de maintenance ou pas pour la meme situation. J'aime pas.

Pour ma part j'utilise la fonction avec tout les arguments sans aucun par défaut pour la argument qui ont été dis plus haut.
Ensuite spécifier des fonctions avec les arguments possibles comme la dis JolyLoic

Citation:

---

J'ai besoin de plus de flexibilité que ce que m'apportent les arguments par défaut, genre f(int, int, string), que je veux pouvoir appeler f(int, int) ou f(int string)

---

par exemple:

Code:

---

1 2 3

int f(int,int,string){} int f(int a,int b){return f(a, b, "defaut");} //etc...

---

Les compilateurs actuels et de qualité donneront un code avec un coup 0, et cela facilite la maintenance(pas de copier-coller), le code est clairement auto-documenté et affiche correctement la liste d'argument avec les "intellisense".

Je tiens à faire une en plus,

Lorsque je suis confronté à un ajout d'un paramètre ( constructeur bien souvent ) il se peut que soit:
- Je met le nouveau paramètre par défaut, pour avoir un code qui compile ( il y a surement une erreur de design par la suite ) ( ou lors des phases d'essai )
- Je ne le met par défaut, pour faire évolué tous les appels du programme à cette fonction en utilisant les erreurs du compilateur ...

Sinon, j'ai l'impression que l'on en viens à la conclusion que les deux techniques fonctionnent et font la même chose ... après cela dépend de cas précis qui donne l'un et l'autre comme mieux ...

Oui, mais comment faites-vous si vous avez une fonction de la forme
f(int,string) comme le précise JolyLoic ?
Pour moi, il faut distinguer d'une part les fonctions qui font la même chose, et retournent une valeur du même type, d'autre part les fonctions qui admettent la plupart du temps un ou des paramètres avec valeur par défaut. C'est à dire que je distingue bien "valeur par défaut" de "paramètre présent ou pas"
Dans le premier cas, c'est la surcharge qui doit être préférée, dans le second cas, les paramètres avec valeur par défaut.
Ces deux cas ne sont pas opposables ni contradictoires, ces deux méthodes peuvent être utilisées pour la même fonction, simplement, il ne s'agit pas du même but à atteindre.