Luc Hermitte writes:
| Je savais que l'on ne pouvait pas passer d'objets non-POD dans
| l'ellipse, mais là je viens de découvrir un autre truc qui m'a quel que
| peu surpris.
| Si le dernier *paramètre formel* *avant* l'ellipse est un non-POD, al ors
| le compilateur se plaint que l'on a passé un non-POD à va_start.
|
| C'est un comportement normal, ou bien il s'agit d'une excentricité
| d'un compilateur incapable de calculer le début de la pile bien qu'il
| dispose de tout le nécessaire pour connaitre le type du paramètre à
| l'intérieur du code appelé ?
Excentricité du programmeur.
Passer un non-POD comment argumnent dans une position '...' invoque un
comportement indéfini. Un compilateur non-excentrique pourrait
reformater le disque dur.
Luc Hermitte <luc.hermi...@gmail.com> writes:
| Je savais que l'on ne pouvait pas passer d'objets non-POD dans
| l'ellipse, mais là je viens de découvrir un autre truc qui m'a quel que
| peu surpris.
| Si le dernier *paramètre formel* *avant* l'ellipse est un non-POD, al ors
| le compilateur se plaint que l'on a passé un non-POD à va_start.
|
| C'est un comportement normal, ou bien il s'agit d'une excentricité
| d'un compilateur incapable de calculer le début de la pile bien qu'il
| dispose de tout le nécessaire pour connaitre le type du paramètre à
| l'intérieur du code appelé ?
Excentricité du programmeur.
Passer un non-POD comment argumnent dans une position '...' invoque un
comportement indéfini. Un compilateur non-excentrique pourrait
reformater le disque dur.
Luc Hermitte writes:
| Je savais que l'on ne pouvait pas passer d'objets non-POD dans
| l'ellipse, mais là je viens de découvrir un autre truc qui m'a quel que
| peu surpris.
| Si le dernier *paramètre formel* *avant* l'ellipse est un non-POD, al ors
| le compilateur se plaint que l'on a passé un non-POD à va_start.
|
| C'est un comportement normal, ou bien il s'agit d'une excentricité
| d'un compilateur incapable de calculer le début de la pile bien qu'il
| dispose de tout le nécessaire pour connaitre le type du paramètre à
| l'intérieur du code appelé ?
Excentricité du programmeur.
Passer un non-POD comment argumnent dans une position '...' invoque un
comportement indéfini. Un compilateur non-excentrique pourrait
reformater le disque dur.
On 29 mai, 16:29, Gabriel Dos Reis wrote:Luc Hermitte writes:
| Je savais que l'on ne pouvait pas passer d'objets non-POD dans
| l'ellipse, mais là je viens de découvrir un autre truc qui m'a quelque
| peu surpris.
| Si le dernier *paramètre formel* *avant* l'ellipse est un non-POD, alors
| le compilateur se plaint que l'on a passé un non-POD à va_start.
|
| C'est un comportement normal, ou bien il s'agit d'une excentricité
| d'un compilateur incapable de calculer le début de la pile bien qu'il
| dispose de tout le nécessaire pour connaitre le type du paramètre à
| l'intérieur du code appelé ?
Excentricité du programmeur.
Passer un non-POD comment argumnent dans une position '...' invoque un
comportement indéfini. Un compilateur non-excentrique pourrait
reformater le disque dur.
Justement, je ne passe pas le non POD dans l'ellipse (cf "paramètre
formel" et "avant l'ellipse" dans mon message original). Je le passe
avant. Comme dans:
void f(std::string s, ...) { // volontairement par copie: j'avais
vu le
va_list ap; // problème avec un autre petit type
pris par copie
va_start(ap, s); // <- le compilateur n'est pas content ici
...
f("toto %i titi %s tutu %pn", 42, "foobar", (void*)ptr);
On 29 mai, 16:29, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
Luc Hermitte <luc.hermi...@gmail.com> writes:
| Je savais que l'on ne pouvait pas passer d'objets non-POD dans
| l'ellipse, mais là je viens de découvrir un autre truc qui m'a quelque
| peu surpris.
| Si le dernier *paramètre formel* *avant* l'ellipse est un non-POD, alors
| le compilateur se plaint que l'on a passé un non-POD à va_start.
|
| C'est un comportement normal, ou bien il s'agit d'une excentricité
| d'un compilateur incapable de calculer le début de la pile bien qu'il
| dispose de tout le nécessaire pour connaitre le type du paramètre à
| l'intérieur du code appelé ?
Excentricité du programmeur.
Passer un non-POD comment argumnent dans une position '...' invoque un
comportement indéfini. Un compilateur non-excentrique pourrait
reformater le disque dur.
Justement, je ne passe pas le non POD dans l'ellipse (cf "paramètre
formel" et "avant l'ellipse" dans mon message original). Je le passe
avant. Comme dans:
void f(std::string s, ...) { // volontairement par copie: j'avais
vu le
va_list ap; // problème avec un autre petit type
pris par copie
va_start(ap, s); // <- le compilateur n'est pas content ici
...
f("toto %i titi %s tutu %pn", 42, "foobar", (void*)ptr);
On 29 mai, 16:29, Gabriel Dos Reis wrote:Luc Hermitte writes:
| Je savais que l'on ne pouvait pas passer d'objets non-POD dans
| l'ellipse, mais là je viens de découvrir un autre truc qui m'a quelque
| peu surpris.
| Si le dernier *paramètre formel* *avant* l'ellipse est un non-POD, alors
| le compilateur se plaint que l'on a passé un non-POD à va_start.
|
| C'est un comportement normal, ou bien il s'agit d'une excentricité
| d'un compilateur incapable de calculer le début de la pile bien qu'il
| dispose de tout le nécessaire pour connaitre le type du paramètre à
| l'intérieur du code appelé ?
Excentricité du programmeur.
Passer un non-POD comment argumnent dans une position '...' invoque un
comportement indéfini. Un compilateur non-excentrique pourrait
reformater le disque dur.
Justement, je ne passe pas le non POD dans l'ellipse (cf "paramètre
formel" et "avant l'ellipse" dans mon message original). Je le passe
avant. Comme dans:
void f(std::string s, ...) { // volontairement par copie: j'avais
vu le
va_list ap; // problème avec un autre petit type
pris par copie
va_start(ap, s); // <- le compilateur n'est pas content ici
...
f("toto %i titi %s tutu %pn", 42, "foobar", (void*)ptr);
Ceci dit, l'idiome C++ utilisant un operateur autre que la virgule
pour passer un nombre variable de "paramètre" est avantageux par
rapport à va_list:
// pseudo-code:
( format("toto %i titi %s tutu %pn") % 42 % "foobar" % (void*)ptr ).p rint;
Voir par exemple boost::format.
Ceci dit, l'idiome C++ utilisant un operateur autre que la virgule
pour passer un nombre variable de "paramètre" est avantageux par
rapport à va_list:
// pseudo-code:
( format("toto %i titi %s tutu %pn") % 42 % "foobar" % (void*)ptr ).p rint;
Voir par exemple boost::format.
Ceci dit, l'idiome C++ utilisant un operateur autre que la virgule
pour passer un nombre variable de "paramètre" est avantageux par
rapport à va_list:
// pseudo-code:
( format("toto %i titi %s tutu %pn") % 42 % "foobar" % (void*)ptr ).p rint;
Voir par exemple boost::format.
Je savais que l'on ne pouvait pas passer d'objets non-POD dans
l'ellipse, mais là je viens de découvrir un autre truc qui m'a
quelque peu surpris. Si le dernier paramètre formel avant
l'ellipse est un non-POD, alors le compilateur se plaint que
l'on a passé un non-POD à va_start.
C'est un comportement normal, ou bien il s'agit d'une
excentricité d'un compilateur incapable de calculer le début
de la pile bien qu'il dispose de tout le nécessaire pour
connaitre le type du paramètre à l'intérieur du code appelé ?
Je savais que l'on ne pouvait pas passer d'objets non-POD dans
l'ellipse, mais là je viens de découvrir un autre truc qui m'a
quelque peu surpris. Si le dernier paramètre formel avant
l'ellipse est un non-POD, alors le compilateur se plaint que
l'on a passé un non-POD à va_start.
C'est un comportement normal, ou bien il s'agit d'une
excentricité d'un compilateur incapable de calculer le début
de la pile bien qu'il dispose de tout le nécessaire pour
connaitre le type du paramètre à l'intérieur du code appelé ?
Je savais que l'on ne pouvait pas passer d'objets non-POD dans
l'ellipse, mais là je viens de découvrir un autre truc qui m'a
quelque peu surpris. Si le dernier paramètre formel avant
l'ellipse est un non-POD, alors le compilateur se plaint que
l'on a passé un non-POD à va_start.
C'est un comportement normal, ou bien il s'agit d'une
excentricité d'un compilateur incapable de calculer le début
de la pile bien qu'il dispose de tout le nécessaire pour
connaitre le type du paramètre à l'intérieur du code appelé ?
Luc Hermitte writes:
> On 29 mai, 16:29, Gabriel Dos Reis wrote:
>> Luc Hermitte writes:
Ceci dit, l'idiome C++ utilisant un operateur autre que la
virgule pour passer un nombre variable de "paramètre" est
avantageux par rapport à va_list:
// pseudo-code:
( format("toto %i titi %s tutu %pn") % 42 % "foobar" % (void*)ptr ).pri nt;
Voir par exemple boost::format.
Luc Hermitte <luc.hermi...@gmail.com> writes:
> On 29 mai, 16:29, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
>> Luc Hermitte <luc.hermi...@gmail.com> writes:
Ceci dit, l'idiome C++ utilisant un operateur autre que la
virgule pour passer un nombre variable de "paramètre" est
avantageux par rapport à va_list:
// pseudo-code:
( format("toto %i titi %s tutu %pn") % 42 % "foobar" % (void*)ptr ).pri nt;
Voir par exemple boost::format.
Luc Hermitte writes:
> On 29 mai, 16:29, Gabriel Dos Reis wrote:
>> Luc Hermitte writes:
Ceci dit, l'idiome C++ utilisant un operateur autre que la
virgule pour passer un nombre variable de "paramètre" est
avantageux par rapport à va_list:
// pseudo-code:
( format("toto %i titi %s tutu %pn") % 42 % "foobar" % (void*)ptr ).pri nt;
Voir par exemple boost::format.
Mais passer le résultat ainsi construit (i.e. la liste des paramètres)
à une fonction variadique (venant de l'API de JNI) n'est pas une chose
que je trouve particulièrement aisée. Ou alors il y a une macro qui
m'a échappé.
Mais passer le résultat ainsi construit (i.e. la liste des paramètres)
à une fonction variadique (venant de l'API de JNI) n'est pas une chose
que je trouve particulièrement aisée. Ou alors il y a une macro qui
m'a échappé.
Mais passer le résultat ainsi construit (i.e. la liste des paramètres)
à une fonction variadique (venant de l'API de JNI) n'est pas une chose
que je trouve particulièrement aisée. Ou alors il y a une macro qui
m'a échappé.
Luc Hermitte writes:
| Je savais que l'on ne pouvait pas passer d'objets non-POD dans
| l'ellipse, mais là je viens de découvrir un autre truc qui m 'a quelque
| peu surpris.
| Si le dernier *paramètre formel* *avant* l'ellipse est un non-POD , alors
| le compilateur se plaint que l'on a passé un non-POD à va_st art.
|
| C'est un comportement normal, ou bien il s'agit d'une excentricité
| d'un compilateur incapable de calculer le début de la pile bien q u'il
| dispose de tout le nécessaire pour connaitre le type du paramà ¨tre Ã
| l'intérieur du code appelé ?
Excentricité du programmeur.
Passer un non-POD comment argumnent dans une position '...' invoque un
comportement indéfini. Un compilateur non-excentrique pourrait
reformater le disque dur.
Luc Hermitte <luc.hermi...@gmail.com> writes:
| Je savais que l'on ne pouvait pas passer d'objets non-POD dans
| l'ellipse, mais là je viens de découvrir un autre truc qui m 'a quelque
| peu surpris.
| Si le dernier *paramètre formel* *avant* l'ellipse est un non-POD , alors
| le compilateur se plaint que l'on a passé un non-POD à va_st art.
|
| C'est un comportement normal, ou bien il s'agit d'une excentricité
| d'un compilateur incapable de calculer le début de la pile bien q u'il
| dispose de tout le nécessaire pour connaitre le type du paramà ¨tre Ã
| l'intérieur du code appelé ?
Excentricité du programmeur.
Passer un non-POD comment argumnent dans une position '...' invoque un
comportement indéfini. Un compilateur non-excentrique pourrait
reformater le disque dur.
Luc Hermitte writes:
| Je savais que l'on ne pouvait pas passer d'objets non-POD dans
| l'ellipse, mais là je viens de découvrir un autre truc qui m 'a quelque
| peu surpris.
| Si le dernier *paramètre formel* *avant* l'ellipse est un non-POD , alors
| le compilateur se plaint que l'on a passé un non-POD à va_st art.
|
| C'est un comportement normal, ou bien il s'agit d'une excentricité
| d'un compilateur incapable de calculer le début de la pile bien q u'il
| dispose de tout le nécessaire pour connaitre le type du paramà ¨tre Ã
| l'intérieur du code appelé ?
Excentricité du programmeur.
Passer un non-POD comment argumnent dans une position '...' invoque un
comportement indéfini. Un compilateur non-excentrique pourrait
reformater le disque dur.
Luc Hermitte a écrit :
> Mais passer le résultat ainsi construit (i.e. la liste des paramètr es)
> à une fonction variadique (venant de l'API de JNI) n'est pas une chos e
> que je trouve particulièrement aisée. Ou alors il y a une macro qui
> m'a échappé.
chaque fonction variadique de jni.h est surchargée en triplet:
1- définition avec ...
2- définition avec paramètre formel va_list
3- définition avec paramètre formel const jvalue*
(où jvalue est une union de tous les types JNI).
il est aisé d'utiliser un jvalue[] (alloué localement) pour utiliser
la 3ième surcharge.
à noter également qu'une std::string a peu (aucun) point commun
avec le type jstring utilisé par JNI, l'exemple fourni avec une
std::string risque de ne pas donner le résultat souhaité même
s'il passait le "..."
Luc Hermitte a écrit :
> Mais passer le résultat ainsi construit (i.e. la liste des paramètr es)
> à une fonction variadique (venant de l'API de JNI) n'est pas une chos e
> que je trouve particulièrement aisée. Ou alors il y a une macro qui
> m'a échappé.
chaque fonction variadique de jni.h est surchargée en triplet:
1- définition avec ...
2- définition avec paramètre formel va_list
3- définition avec paramètre formel const jvalue*
(où jvalue est une union de tous les types JNI).
il est aisé d'utiliser un jvalue[] (alloué localement) pour utiliser
la 3ième surcharge.
à noter également qu'une std::string a peu (aucun) point commun
avec le type jstring utilisé par JNI, l'exemple fourni avec une
std::string risque de ne pas donner le résultat souhaité même
s'il passait le "..."
Luc Hermitte a écrit :
> Mais passer le résultat ainsi construit (i.e. la liste des paramètr es)
> à une fonction variadique (venant de l'API de JNI) n'est pas une chos e
> que je trouve particulièrement aisée. Ou alors il y a une macro qui
> m'a échappé.
chaque fonction variadique de jni.h est surchargée en triplet:
1- définition avec ...
2- définition avec paramètre formel va_list
3- définition avec paramètre formel const jvalue*
(où jvalue est une union de tous les types JNI).
il est aisé d'utiliser un jvalue[] (alloué localement) pour utiliser
la 3ième surcharge.
à noter également qu'une std::string a peu (aucun) point commun
avec le type jstring utilisé par JNI, l'exemple fourni avec une
std::string risque de ne pas donner le résultat souhaité même
s'il passait le "..."
Le compilateur a raison. 18.7/3:
The restrictions that ISO C places on the second parameter to the
va_start() macro in header <stdarg.h> are different in this
International Standard. The parameter parmN is the identifier of t he
rightmost parameter in the variable parameter list of the function
definition (the one just before the ...). If the parameter parm N is
declared with a function, array, or reference type, or with a type
that is not compatible with the type that results when passing an
argument for which there is no parameter, the behavior is
undefined.
Le compilateur a raison. 18.7/3:
The restrictions that ISO C places on the second parameter to the
va_start() macro in header <stdarg.h> are different in this
International Standard. The parameter parmN is the identifier of t he
rightmost parameter in the variable parameter list of the function
definition (the one just before the ...). If the parameter parm N is
declared with a function, array, or reference type, or with a type
that is not compatible with the type that results when passing an
argument for which there is no parameter, the behavior is
undefined.
Le compilateur a raison. 18.7/3:
The restrictions that ISO C places on the second parameter to the
va_start() macro in header <stdarg.h> are different in this
International Standard. The parameter parmN is the identifier of t he
rightmost parameter in the variable parameter list of the function
definition (the one just before the ...). If the parameter parm N is
declared with a function, array, or reference type, or with a type
that is not compatible with the type that results when passing an
argument for which there is no parameter, the behavior is
undefined.