Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Bertrand Motuelle
Vincent Lascaux wrote:
Quel doit etre, selon la norme, le comportement du code suivant :
void f(double a) { std::cout << "double" << std::endl; } void f(int& a) { std::cout << "int&" << std::endl; } int g() { return 12; }
int main() { f(1); f(g()); }
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas "viable" pour la resolution de surcharge (necessite de "binder" une reference non const sur une rvalue)
Donc le resultat devrait etre: double double
Bertrand.
Vincent Lascaux wrote:
Quel doit etre, selon la norme, le comportement du code suivant :
void f(double a) { std::cout << "double" << std::endl; }
void f(int& a) { std::cout << "int&" << std::endl; }
int g() { return 12; }
int main()
{
f(1);
f(g());
}
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas
"viable" pour la resolution de surcharge (necessite de "binder" une
reference non const sur une rvalue)
Quel doit etre, selon la norme, le comportement du code suivant :
void f(double a) { std::cout << "double" << std::endl; } void f(int& a) { std::cout << "int&" << std::endl; } int g() { return 12; }
int main() { f(1); f(g()); }
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas "viable" pour la resolution de surcharge (necessite de "binder" une reference non const sur une rvalue)
Donc le resultat devrait etre: double double
Bertrand.
Vincent Lascaux
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas "viable" pour la resolution de surcharge (necessite de "binder" une reference non const sur une rvalue)
Est ce que ca signifie qu'un compilateur qui compile ca :
void foo(int&) { } int main() { foo(1); }
fait une extension à la norme ?
-- Vincent
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas
"viable" pour la resolution de surcharge (necessite de "binder" une
reference non const sur une rvalue)
Est ce que ca signifie qu'un compilateur qui compile ca :
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas "viable" pour la resolution de surcharge (necessite de "binder" une reference non const sur une rvalue)
Est ce que ca signifie qu'un compilateur qui compile ca :
void foo(int&) { } int main() { foo(1); }
fait une extension à la norme ?
-- Vincent
Loïc Joly
Vincent Lascaux wrote:
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas "viable" pour la resolution de surcharge (necessite de "binder" une reference non const sur une rvalue)
Est ce que ca signifie qu'un compilateur qui compile ca :
void foo(int&) { } int main() { foo(1); }
fait une extension à la norme ?
Ce code n'est pas valide.
void foo(int const &) { }
Il le devient
-- Loïc
Vincent Lascaux wrote:
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas
"viable" pour la resolution de surcharge (necessite de "binder" une
reference non const sur une rvalue)
Est ce que ca signifie qu'un compilateur qui compile ca :
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas "viable" pour la resolution de surcharge (necessite de "binder" une reference non const sur une rvalue)
Est ce que ca signifie qu'un compilateur qui compile ca :
void foo(int&) { } int main() { foo(1); }
fait une extension à la norme ?
Ce code n'est pas valide.
void foo(int const &) { }
Il le devient
-- Loïc
Michel Michaud
Dans news:3fd64f8e$0$24050$, Vincent
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas "viable" pour la resolution de surcharge (necessite de "binder" une reference non const sur une rvalue)
Est ce que ca signifie qu'un compilateur qui compile ca :
void foo(int&) { } int main() { foo(1); }
fait une extension à la norme ?
Oui, donc c'est du code illégal par rapport à la norme. Par contre, c'était du code initialement accepté par C++ (de bien avant la norme), mais qui semblait trop surprenant : un temporaire était créé et c'est lui qui pouvait être modifié par la fonction...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:3fd64f8e$0$24050$626a54ce@news.free.fr, Vincent
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas
"viable" pour la resolution de surcharge (necessite de "binder" une
reference non const sur une rvalue)
Est ce que ca signifie qu'un compilateur qui compile ca :
void foo(int&) { }
int main() { foo(1); }
fait une extension à la norme ?
Oui, donc c'est du code illégal par rapport à la norme. Par
contre, c'était du code initialement accepté par C++ (de bien
avant la norme), mais qui semblait trop surprenant : un
temporaire était créé et c'est lui qui pouvait être modifié
par la fonction...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas "viable" pour la resolution de surcharge (necessite de "binder" une reference non const sur une rvalue)
Est ce que ca signifie qu'un compilateur qui compile ca :
void foo(int&) { } int main() { foo(1); }
fait une extension à la norme ?
Oui, donc c'est du code illégal par rapport à la norme. Par contre, c'était du code initialement accepté par C++ (de bien avant la norme), mais qui semblait trop surprenant : un temporaire était créé et c'est lui qui pouvait être modifié par la fonction...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Alexandre
"Vincent Lascaux" a écrit dans le message de news:3fd64f8e$0$24050$
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas "viable" pour la resolution de surcharge (necessite de "binder" une reference non const sur une rvalue)
Est ce que ca signifie qu'un compilateur qui compile ca :
void foo(int&) { } int main() { foo(1); }
fait une extension à la norme ?
-- Oui, le code n'est pas "légal". D'ailleurs les compilos mettent souvent un
warning sur ce genre de choses, s'ils le compilent. avec un const ça passe.
"Vincent Lascaux" <nospam@nospam.org> a écrit dans le message de
news:3fd64f8e$0$24050$626a54ce@news.free.fr...
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas
"viable" pour la resolution de surcharge (necessite de "binder" une
reference non const sur une rvalue)
Est ce que ca signifie qu'un compilateur qui compile ca :
void foo(int&) { }
int main() { foo(1); }
fait une extension à la norme ?
--
Oui, le code n'est pas "légal". D'ailleurs les compilos mettent souvent un
warning sur ce genre de choses, s'ils le compilent. avec un const ça passe.
"Vincent Lascaux" a écrit dans le message de news:3fd64f8e$0$24050$
D'apres ma lecture de 13.3.2/3 et 13.3.3.1.4/3, f(int&) n'est pas "viable" pour la resolution de surcharge (necessite de "binder" une reference non const sur une rvalue)
Est ce que ca signifie qu'un compilateur qui compile ca :
void foo(int&) { } int main() { foo(1); }
fait une extension à la norme ?
-- Oui, le code n'est pas "légal". D'ailleurs les compilos mettent souvent un
warning sur ce genre de choses, s'ils le compilent. avec un const ça passe.
Alexandre
"Vincent Lascaux" a écrit dans le message de news:3fd63751$0$7133$
Bonjour,
Quel doit etre, selon la norme, le comportement du code suivant :
void f(double a) { std::cout << "double" << std::endl; } void f(int& a) { std::cout << "int&" << std::endl; } int g() { return 12; }
int main() { f(1); f(g()); }
Merci
-- Vincent
Je dirais aussi double à chaque fois, car il est bien difficile de
considerer 12 comme une variable... Par contre, si le proto de f est f(const int& ) alors à mon avis c'est cette version qui est appelée.
"Vincent Lascaux" <nospam@nospam.org> a écrit dans le message de
news:3fd63751$0$7133$626a54ce@news.free.fr...
Bonjour,
Quel doit etre, selon la norme, le comportement du code suivant :
void f(double a) { std::cout << "double" << std::endl; }
void f(int& a) { std::cout << "int&" << std::endl; }
int g() { return 12; }
int main()
{
f(1);
f(g());
}
Merci
--
Vincent
Je dirais aussi double à chaque fois, car il est bien difficile de
considerer 12 comme une variable...
Par contre, si le proto de f est f(const int& ) alors à mon avis c'est cette
version qui est appelée.
