Nombre variable de paramètres

Bonjour. Ma question est toute simple. Je viens de m'apercevoir que ceci compile (que ce soit avec gcc, BCB, ou VisualC++, j'ai pu tout tester):

Code:

---

1 2 3 4

void func(...) { }

---

Autrement dit, il n'est pas nécessaire que la fonction ait au moins un paramètre classique.
Qu'en est-il exactement, que dit le standard à ce sujet ? Car dans tout ce que j'ai pu lire, il est indiqué que la fonction doit au moins avoir un paramètre classique, comme çà:

Code:

---

1 2 3 4

void func(char* sz, ...) { }

---

De plus, si on a pas moyen de savoir le nombre d'arguments effectivement passés, comment les récupérer ? Si ce n'est pas possible, quel est l'intérêt d'autoriser une telle syntaxe ?

Merci d'avance.

La norme dit :

Citation:

---

If the parameter-declaration-clause terminates with an ellipsis, the number of arguments shall be equal to or greater than the number of parameters specified. Where syntactically correct, “, ...” is synonymous with “...”.

---

Rien n'interdit d'avoir un seul argument.

Maintenant, comment y accèder ? Les macros va_arg va_end et va_start et le type va_list semblent là pour ça, mais comme la norme C++ ne les définit que par référence à la norme C que je n'ai pas, je ne peux pas en dire plus.

Citation:

---

Envoyé par JolyLoic

Les macros va_arg va_end et va_start et le type va_list semblent là pour ça, mais comme la norme C++ ne les définit que par référence à la norme C que je n'ai pas, je ne peux pas en dire plus.

---

Je sais çà, mais comment sais-tu où t'arréter dans la récupération des arguments si tu n'en a pas le nombre ?
Exemple tiré du cours d'Emmanuel Delahaye:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#include <stdarg.h>   /* Fonction effectuant la somme de "compte" paramètres : */ double somme(int compte, ...) { double resultat=0; /* Variable stockant la somme. */ va_list varg; /* Variable identifiant le prochain   paramètre. */ va_start(varg, compte); /* Initialisation de la liste. */ while (compte!=0) /* Parcours de la liste. */ { resultat=resultat+va_arg(varg, double); compte=compte-1; } va_end(varg); /* Terminaison. */ return resultat; }

---

Sans la variable compte, comment pourrait-on faire ?

Effectivement, en lisant la spec de ces macros (que comme j'ai dit, je ne connais pas, puisque je n'ai jamais eu besoin de les utiliser en C++, je trouve que le chaînage d'appel à la cout est supérieur aux varargs), j'ai l'impression que sans un argument classique, on a du mal à utiliser va_begin. Je ne comprend pas trop pourquoi.

En effet, il me semble légitime dans ce contexte de vouloir créer une fonction concat qui concatène n char*, et qui s'appelle ainsi :

Code:

---

1 2	char *JeanPoiret = concat("La ", "vache ", "à ", "mille ", "francs", NULL);

---

Ma conclusion sur ce point est donc que l'on peut écrire une fonction int f(...), mais que dans ce cas, il n'est pas possible d'accèder aux arguments.

Citation:

---

Envoyé par JolyLoic

En effet, il me semble légitime dans ce contexte de vouloir créer une fonction concat qui concatène n char*, et qui s'appelle ainsi :

Code:

---

1 2	char *JeanPoiret = concat("La ", "vache ", "à ", "mille ", "francs", NULL);

---

---

Oui et pourtant c'est impossible ! Mais comme tu dis, dans ce cas, une classe utilisant l'opérateur << résoud le problème.

Citation:

---

Envoyé par JolyLoic

je trouve que le chaînage d'appel à la cout est supérieur aux varargs),

---

si je comprends bien: cela remplace ce qu'on peut faire avec stdarg ?
y'a-t-il des infos qq part car j'ai lu qu'il y avait une solution meilleure proposée plus tard (dans le cours Eckel) mais je n'ai jamais trouvé.
Merci d'avance.

Le tout est d'avoir un moyen de stocker le nombre d'arguments. Après à l'exécution on n'aura pas vraiment de moyen de tester ce nombre ; il faut supposer que l'utilisateur ne se plante pas.

Dans la famille C, les façons de stocker ce nombre :
- si le premier truc reçu sera le nombre ou un format d'où il est extractible,
- si on utilise un 0 terminal (là, problème aussi de format des choses reçues)
- si le nombre est connu par ailleurs (genre tu peuples un vecteur qui est connu pour avoir 4 éléments)

Dans les solutions C++, pour remplacer "...", on a :
- les plages itérables (pour lesquelles on connait donc deux bornes) et autres vecteurs ; que cela soit pour des données homogènes, ou même hétérogènes si on utilise des paramètres variants.
- l'opérateur d'injection ou toute autre fonction utilisée pour injecter.
- et aussi variante (je l'aime bien celle là) utiliser une classe (éventuellement proxy) qui se définit l'opérateur () (qui renvoit le proxy d'abord, puis *this), ce qui permet d'écrire des choses comme:

Code:

---

1 2	Toto toto(p1, p2, p3) ("toto") (42) (M_PI) (titi)

---

Citation:

---

Envoyé par JolyLoic

Effectivement, en lisant la spec de ces macros (que comme j'ai dit, je ne connais pas, puisque je n'ai jamais eu besoin de les utiliser en C++, je trouve que le chaînage d'appel à la cout est supérieur aux varargs), j'ai l'impression que sans un argument classique, on a du mal à utiliser va_begin. Je ne comprend pas trop pourquoi.

En effet, il me semble légitime dans ce contexte de vouloir créer une fonction concat qui concatène n char*, et qui s'appelle ainsi :

Code:

---

1 2	char *JeanPoiret = concat("La ", "vache ", "à ", "mille ", "francs", NULL);

---

Ma conclusion sur ce point est donc que l'on peut écrire une fonction int f(...), mais que dans ce cas, il n'est pas possible d'accèder aux arguments.

---

Il faut un premier argument avant ... qui permet d'identifier le type et le nombre de valeurs qui lui sont passées. Que se passerait-il si on passait ça :

Code:

---

concat("La ", "vache ", "à ", 1000, " francs", NULL);

---

Sinon on avait déjà parlé de ça ici :
http://www.developpez.net/forums/viewtopic.php?t=248470

Luc> c'est quoi l'opérateur d'injection ?
Et sinon on ne peut pas arriver à quelque chose en surchargeant l'opérateur virgule ?

En fait, je pense que le premier argument sert surtout à récupérer l'adresse du premier argument optionnel sur la pile (celui juste après donc), ce que fait la macro va_begin. Sans cet argument, comment récupérer l'adresse des arguments variables ?
Si on se sert d'une variable terminale (NULL) plutot que d'une chaîne decrivant le format il faut faire confiance à l'utilisateur, en l'occurence il ne devra pas donner autre chose que du char* à concat(), mais à part cette restriction c'est tout à fait possible. Apres tout, même avec une chaine decrivant le format, rien ne nous empeche de nous gourrer (ce qui m'arrive d'ailleurs souvent lorsque j'utilise scanf & compagnie :lol:).

L'opérateur d'injection c'est <<, >> est l'opérateur d'extraction (enfin c'est toujours de cette manière qu'on en parle, en tout cas).

Pour l'opérateur virgule, on peut faire des trucs amusants ; j'avais codé un bidule qui permettait d'écrire quelque chose comme ça :

Code:

---

std::vector<int> v = 1, 2, 3, 5, 6, 7;

---

Mais à part pour s'amuser, je n'ai jamais vu de surcharge de cet opérateur, je ne sais pas si c'est une si bonne solution. Autant surcharger l'opérateur <<, ça revient plus ou moins au même je pense.

Disons que l'opérateur virgule, ça va bien mais pas pour n'importe quoi.
Je n'ose même pas imaginer les effets de bords avec l'écriture présente où il n'y a que des entiers : à droite comme à gauche.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Que se passerait-il si on passait ça :

Code:

---

concat("La ", "vache ", "à ", 1000, " francs", NULL);

---

---

La même chose que si on passe un mauvais argument à un printf : Boom ! De préférence plus loin dans le code, à un endroit sans rapport. C'est après avoir passé plus d'une journée à temps plein à débugger une telle horeur (et on ajoute des printf de debug, et l'erreur change d'endroit...) que j'ai achevé de bannir printf et les varargs de mon vocabulaire.

Citation:

---

Envoyé par Luc Hermitte

Disons que l'opérateur virgule, ça va bien mais pas pour n'importe quoi.
Je n'ose même pas imaginer les effets de bords avec l'écriture présente où il n'y a que des entiers : à droite comme à gauche.

---

Ca marche bien, parce que l'opérateur = est prioritaire par rapport à l'opérateur ,

De mémoir, les gens de blitz ou d'autre bibliothèques de ce genre utilisent cette syntaxe pour initialiser les tableaux.

Je n'avais pas percuté ce détail dans les priorités.