j'ai besoin d'avoir un vector vide par defaut dans un constructor.
Ai-je le droit de faire un truc comme ca (ca compile avec VC++ mais je
prefere etre sur...)?
A::A(std::vector<B*>& b = std::vector<B*>());
Si oui, est-ce une bonne solution?
Sinon, quelle est la solution?
j'ai besoin d'avoir un vector vide par defaut dans un constructor. Ai-je le droit de faire un truc comme ca (ca compile avec VC++ mais je prefere etre sur...)?
A::A(std::vector<B*>& b = std::vector<B*>());
Ca me semble correcte. J'ajouterais juste que b devrait être "const".
-- Guillaume Brocker
Beubeu wrote:
j'ai besoin d'avoir un vector vide par defaut dans un constructor.
Ai-je le droit de faire un truc comme ca (ca compile avec VC++ mais je
prefere etre sur...)?
A::A(std::vector<B*>& b = std::vector<B*>());
Ca me semble correcte. J'ajouterais juste que b devrait être "const".
j'ai besoin d'avoir un vector vide par defaut dans un constructor. Ai-je le droit de faire un truc comme ca (ca compile avec VC++ mais je prefere etre sur...)?
A::A(std::vector<B*>& b = std::vector<B*>());
Ca me semble correcte. J'ajouterais juste que b devrait être "const".
-- Guillaume Brocker
Fabien LE LEZ
On Thu, 06 May 2004 14:58:42 +0200, Beubeu wrote:
Ai-je le droit de faire un truc comme ca (ca compile avec VC++ mais je prefere etre sur...)?
A::A(std::vector<B*>& b = std::vector<B*>());
Sans const, il me semble que non. D'ailleurs, je ne vois pas bien ce que ça peut signifier.
Puisque le constructeur de A doit modifier son paramètre, ne pas donner de paramètre (i.e. utiliser celui par défaut) a (il me semble) de grosses conséquences, et justifierait de créer deux fonctions :
A::A (std::vector<B*>&) { ... } A::A () { ... }
Par contre, l'écriture suivante ne me paraît pas poser le moindre problème :
A::A(std::vector<B*> const& b = std::vector<B*>()) { ... }
... mais la signification est totalement différente (i.e. la fonction ne peut plus modifier le paramètre).
-- ;-) FLL, Epagneul Breton
On Thu, 06 May 2004 14:58:42 +0200, Beubeu <lecallennec@yahoo.fr>
wrote:
Ai-je le droit de faire un truc comme ca (ca compile avec VC++ mais je
prefere etre sur...)?
A::A(std::vector<B*>& b = std::vector<B*>());
Sans const, il me semble que non. D'ailleurs, je ne vois pas bien ce
que ça peut signifier.
Puisque le constructeur de A doit modifier son paramètre, ne pas
donner de paramètre (i.e. utiliser celui par défaut) a (il me semble)
de grosses conséquences, et justifierait de créer deux fonctions :
A::A (std::vector<B*>&) { ... }
A::A () { ... }
Par contre, l'écriture suivante ne me paraît pas poser le moindre
problème :
A::A(std::vector<B*> const& b = std::vector<B*>())
{ ... }
... mais la signification est totalement différente (i.e. la fonction
ne peut plus modifier le paramètre).
Ai-je le droit de faire un truc comme ca (ca compile avec VC++ mais je prefere etre sur...)?
A::A(std::vector<B*>& b = std::vector<B*>());
Sans const, il me semble que non. D'ailleurs, je ne vois pas bien ce que ça peut signifier.
Puisque le constructeur de A doit modifier son paramètre, ne pas donner de paramètre (i.e. utiliser celui par défaut) a (il me semble) de grosses conséquences, et justifierait de créer deux fonctions :
A::A (std::vector<B*>&) { ... } A::A () { ... }
Par contre, l'écriture suivante ne me paraît pas poser le moindre problème :
A::A(std::vector<B*> const& b = std::vector<B*>()) { ... }
... mais la signification est totalement différente (i.e. la fonction ne peut plus modifier le paramètre).
-- ;-) FLL, Epagneul Breton
kanze
Fabien LE LEZ wrote in message news:...
On Thu, 06 May 2004 14:58:42 +0200, Beubeu wrote:
Ai-je le droit de faire un truc comme ca (ca compile avec VC++ mais je prefere etre sur...)?
A::A(std::vector<B*>& b = std::vector<B*>());
Sans const, il me semble que non. D'ailleurs, je ne vois pas bien ce que ça peut signifier.
Je vois bien ce que ça peut signifier, mais comme tu dis, sans const, c'est illégal. Et avec const, je ne vois pas à quoi ça peut servir. Tu as une référence à un vecteur vide que tu ne peux pas modifier. (Strictement parlant, tu peux le modifier au moyen d'un const_cast. Mais si c'est comme ça que tu programmes, je n'aimerais pas à avoir à travailler sur ton code.)
Il ne m'est pas très clair ce dont il a réelement besoin. Sans savoir pourquoi une variable locale ne ferait pas l'affaire, c'est difficile à proposer une autre solution.
Puisque le constructeur de A doit modifier son paramètre, ne pas donner de paramètre (i.e. utiliser celui par défaut) a (il me semble) de grosses conséquences, et justifierait de créer deux fonctions :
A::A (std::vector<B*>&) { ... } A::A () { ... }
OK. Si c'est un paramètre, c'est autre chose. Dans ce cas-là, il faut savoir si le constructeur doit modifier le paramètre, ou si c'est simplement qu'il ne savait pas qu'il fallait utiliser le const autrement.
Par contre, l'écriture suivante ne me paraît pas poser le moindre problème :
A::A(std::vector<B*> const& b = std::vector<B*>()) { ... }
... mais la signification est totalement différente (i.e. la fonction ne peut plus modifier le paramètre).
Je ne dirais pas « totalement différente ». Il y a une restriction en plus, c'est tout.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<hk2l905o904eigvhv9skbmi3ilmddf72rq@4ax.com>...
On Thu, 06 May 2004 14:58:42 +0200, Beubeu <lecallennec@yahoo.fr>
wrote:
Ai-je le droit de faire un truc comme ca (ca compile avec VC++ mais
je prefere etre sur...)?
A::A(std::vector<B*>& b = std::vector<B*>());
Sans const, il me semble que non. D'ailleurs, je ne vois pas bien ce
que ça peut signifier.
Je vois bien ce que ça peut signifier, mais comme tu dis, sans const,
c'est illégal. Et avec const, je ne vois pas à quoi ça peut servir. Tu
as une référence à un vecteur vide que tu ne peux pas modifier.
(Strictement parlant, tu peux le modifier au moyen d'un const_cast. Mais
si c'est comme ça que tu programmes, je n'aimerais pas à avoir à
travailler sur ton code.)
Il ne m'est pas très clair ce dont il a réelement besoin. Sans savoir
pourquoi une variable locale ne ferait pas l'affaire, c'est difficile à
proposer une autre solution.
Puisque le constructeur de A doit modifier son paramètre, ne pas
donner de paramètre (i.e. utiliser celui par défaut) a (il me semble)
de grosses conséquences, et justifierait de créer deux fonctions :
A::A (std::vector<B*>&) { ... }
A::A () { ... }
OK. Si c'est un paramètre, c'est autre chose. Dans ce cas-là, il faut
savoir si le constructeur doit modifier le paramètre, ou si c'est
simplement qu'il ne savait pas qu'il fallait utiliser le const
autrement.
Par contre, l'écriture suivante ne me paraît pas poser le moindre
problème :
A::A(std::vector<B*> const& b = std::vector<B*>())
{ ... }
... mais la signification est totalement différente (i.e. la fonction
ne peut plus modifier le paramètre).
Je ne dirais pas « totalement différente ». Il y a une restriction en
plus, c'est tout.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Ai-je le droit de faire un truc comme ca (ca compile avec VC++ mais je prefere etre sur...)?
A::A(std::vector<B*>& b = std::vector<B*>());
Sans const, il me semble que non. D'ailleurs, je ne vois pas bien ce que ça peut signifier.
Je vois bien ce que ça peut signifier, mais comme tu dis, sans const, c'est illégal. Et avec const, je ne vois pas à quoi ça peut servir. Tu as une référence à un vecteur vide que tu ne peux pas modifier. (Strictement parlant, tu peux le modifier au moyen d'un const_cast. Mais si c'est comme ça que tu programmes, je n'aimerais pas à avoir à travailler sur ton code.)
Il ne m'est pas très clair ce dont il a réelement besoin. Sans savoir pourquoi une variable locale ne ferait pas l'affaire, c'est difficile à proposer une autre solution.
Puisque le constructeur de A doit modifier son paramètre, ne pas donner de paramètre (i.e. utiliser celui par défaut) a (il me semble) de grosses conséquences, et justifierait de créer deux fonctions :
A::A (std::vector<B*>&) { ... } A::A () { ... }
OK. Si c'est un paramètre, c'est autre chose. Dans ce cas-là, il faut savoir si le constructeur doit modifier le paramètre, ou si c'est simplement qu'il ne savait pas qu'il fallait utiliser le const autrement.
Par contre, l'écriture suivante ne me paraît pas poser le moindre problème :
A::A(std::vector<B*> const& b = std::vector<B*>()) { ... }
... mais la signification est totalement différente (i.e. la fonction ne peut plus modifier le paramètre).
Je ne dirais pas « totalement différente ». Il y a une restriction en plus, c'est tout.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
benoit le callennec
Il ne m'est pas très clair ce dont il a réelement besoin. Sans savoir pourquoi une variable locale ne ferait pas l'affaire, c'est difficile à proposer une autre solution. Bonjour,
admettons que je souhaite tout simplement avoir un constructeur qui prend en entree un std::vector pour initialiser ma liste interne ou alors qui initialise ma liste interne a la liste vide si aucun std::vector n'est passe. Quelle est la bonne solution dans ce cas et pourquoi la mienne est si "horrible" que ca? N'hesitez pas a detailler vos reponses car ca m'interesse de bien voir ce qu'il ne faut pas faire.
Merci d'avance, Benoit
Il ne m'est pas très clair ce dont il a réelement besoin. Sans savoir
pourquoi une variable locale ne ferait pas l'affaire, c'est difficile à
proposer une autre solution.
Bonjour,
admettons que je souhaite tout simplement avoir un constructeur qui
prend en entree un std::vector pour initialiser ma liste interne ou
alors qui initialise ma liste interne a la liste vide si aucun
std::vector n'est passe.
Quelle est la bonne solution dans ce cas et pourquoi la mienne est si
"horrible" que ca? N'hesitez pas a detailler vos reponses car ca
m'interesse de bien voir ce qu'il ne faut pas faire.
Il ne m'est pas très clair ce dont il a réelement besoin. Sans savoir pourquoi une variable locale ne ferait pas l'affaire, c'est difficile à proposer une autre solution. Bonjour,
admettons que je souhaite tout simplement avoir un constructeur qui prend en entree un std::vector pour initialiser ma liste interne ou alors qui initialise ma liste interne a la liste vide si aucun std::vector n'est passe. Quelle est la bonne solution dans ce cas et pourquoi la mienne est si "horrible" que ca? N'hesitez pas a detailler vos reponses car ca m'interesse de bien voir ce qu'il ne faut pas faire.
Merci d'avance, Benoit
Beubeu
Il ne m'est pas très clair ce dont il a réelement besoin. Sans savoir pourquoi une variable locale ne ferait pas l'affaire, c'est difficile à proposer une autre solution.
Bonjour,
admettons que je souhaite tout simplement avoir un constructeur qui prend en entree un std::vector pour initialiser ma liste interne ou alors qui initialise ma liste interne a la liste vide si aucun std::vector n'est passe. Quelle est la bonne solution dans ce cas et pourquoi la mienne est si "horrible" que ca? N'hesitez pas a detailler vos reponses car ca m'interesse de bien voir ce qu'il ne faut pas faire.
Merci d'avance, Benoit
Il ne m'est pas très clair ce dont il a réelement besoin. Sans savoir
pourquoi une variable locale ne ferait pas l'affaire, c'est difficile à
proposer une autre solution.
Bonjour,
admettons que je souhaite tout simplement avoir un constructeur qui
prend en entree un std::vector pour initialiser ma liste interne ou
alors qui initialise ma liste interne a la liste vide si aucun
std::vector n'est passe.
Quelle est la bonne solution dans ce cas et pourquoi la mienne est si
"horrible" que ca? N'hesitez pas a detailler vos reponses car ca
m'interesse de bien voir ce qu'il ne faut pas faire.
Il ne m'est pas très clair ce dont il a réelement besoin. Sans savoir pourquoi une variable locale ne ferait pas l'affaire, c'est difficile à proposer une autre solution.
Bonjour,
admettons que je souhaite tout simplement avoir un constructeur qui prend en entree un std::vector pour initialiser ma liste interne ou alors qui initialise ma liste interne a la liste vide si aucun std::vector n'est passe. Quelle est la bonne solution dans ce cas et pourquoi la mienne est si "horrible" que ca? N'hesitez pas a detailler vos reponses car ca m'interesse de bien voir ce qu'il ne faut pas faire.
Merci d'avance, Benoit
Fabien LE LEZ
On 6 May 2004 23:42:17 -0700, wrote:
Et avec const, je ne vois pas à quoi ça peut servir.
C'est à peu près la même chose que
class A { public: A (int parametre= 0); };
A::A(std::vector<B*> const& b = std::vector<B*>()) { ... }
... mais la signification est totalement différente (i.e. la fonction ne peut plus modifier le paramètre).
Je ne dirais pas « totalement différente ».
Disons qu'un paramètre passé par référence constante est un paramètre "normal", i.e. une variable qui donne des informations à la fonction appelée, comme pour un passage par valeur.
Passer un paramètre en référence non constante, au contraire, indique (généralement) que la fonction va modifier le paramètre -- c'est presque une valeur de retour. Pour moi,
void f (int&);
est plus proche de
int f();
que de
void f (int const&);
-- ;-) FLL, Epagneul Breton
On 6 May 2004 23:42:17 -0700, kanze@gabi-soft.fr wrote:
Et avec const, je ne vois pas à quoi ça peut servir.
C'est à peu près la même chose que
class A
{
public:
A (int parametre= 0);
};
A::A(std::vector<B*> const& b = std::vector<B*>())
{ ... }
... mais la signification est totalement différente (i.e. la fonction
ne peut plus modifier le paramètre).
Je ne dirais pas « totalement différente ».
Disons qu'un paramètre passé par référence constante est un paramètre
"normal", i.e. une variable qui donne des informations à la fonction
appelée, comme pour un passage par valeur.
Passer un paramètre en référence non constante, au contraire, indique
(généralement) que la fonction va modifier le paramètre -- c'est
presque une valeur de retour.
Pour moi,
Et avec const, je ne vois pas à quoi ça peut servir.
C'est à peu près la même chose que
class A { public: A (int parametre= 0); };
A::A(std::vector<B*> const& b = std::vector<B*>()) { ... }
... mais la signification est totalement différente (i.e. la fonction ne peut plus modifier le paramètre).
Je ne dirais pas « totalement différente ».
Disons qu'un paramètre passé par référence constante est un paramètre "normal", i.e. une variable qui donne des informations à la fonction appelée, comme pour un passage par valeur.
Passer un paramètre en référence non constante, au contraire, indique (généralement) que la fonction va modifier le paramètre -- c'est presque une valeur de retour. Pour moi,
void f (int&);
est plus proche de
int f();
que de
void f (int const&);
-- ;-) FLL, Epagneul Breton
Fabien LE LEZ
On Fri, 07 May 2004 13:03:32 +0200, Beubeu wrote:
admettons que je souhaite tout simplement avoir un constructeur qui prend en entree un std::vector pour initialiser ma liste interne ou alors qui initialise ma liste interne a la liste vide si aucun std::vector n'est passe.
On Fri, 07 May 2004 13:03:32 +0200, Beubeu <lecallennec@yahoo.fr>
wrote:
admettons que je souhaite tout simplement avoir un constructeur qui
prend en entree un std::vector pour initialiser ma liste interne ou
alors qui initialise ma liste interne a la liste vide si aucun
std::vector n'est passe.
admettons que je souhaite tout simplement avoir un constructeur qui prend en entree un std::vector pour initialiser ma liste interne ou alors qui initialise ma liste interne a la liste vide si aucun std::vector n'est passe.
|> > Il ne m'est pas très clair ce dont il a réelement besoin. |> > Sans savoir pourquoi une variable locale ne ferait pas l'affaire, |> > c'est difficile à proposer une autre solution.
|> admettons que je souhaite tout simplement avoir un constructeur qui |> prend en entree un std::vector pour initialiser ma liste interne ou |> alors qui initialise ma liste interne a la liste vide si aucun |> std::vector n'est passe.
Je n'avais pas saisi qu'il s'agissait d'un paramètre.
|> Quelle est la bonne solution dans ce cas et pourquoi la mienne est |> si "horrible" que ca? N'hesitez pas a detailler vos reponses car ca |> m'interesse de bien voir ce qu'il ne faut pas faire.
En cas d'un paramètre, ta solution est très bien, à condition de declarer la référence const. Si tu ne modifies pas le paramètre, ça marchera sans problème. Et si tu modifies le paramètre, je me poserais d'avantage de questions sur la conception de la classe.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Beubeu <lecallennec@yahoo.fr> writes:
|> > Il ne m'est pas très clair ce dont il a réelement besoin.
|> > Sans savoir pourquoi une variable locale ne ferait pas l'affaire,
|> > c'est difficile à proposer une autre solution.
|> admettons que je souhaite tout simplement avoir un constructeur qui
|> prend en entree un std::vector pour initialiser ma liste interne ou
|> alors qui initialise ma liste interne a la liste vide si aucun
|> std::vector n'est passe.
Je n'avais pas saisi qu'il s'agissait d'un paramètre.
|> Quelle est la bonne solution dans ce cas et pourquoi la mienne est
|> si "horrible" que ca? N'hesitez pas a detailler vos reponses car ca
|> m'interesse de bien voir ce qu'il ne faut pas faire.
En cas d'un paramètre, ta solution est très bien, à condition
de declarer la référence const. Si tu ne modifies pas le
paramètre, ça marchera sans problème. Et si tu modifies le
paramètre, je me poserais d'avantage de questions sur la conception
de la classe.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> > Il ne m'est pas très clair ce dont il a réelement besoin. |> > Sans savoir pourquoi une variable locale ne ferait pas l'affaire, |> > c'est difficile à proposer une autre solution.
|> admettons que je souhaite tout simplement avoir un constructeur qui |> prend en entree un std::vector pour initialiser ma liste interne ou |> alors qui initialise ma liste interne a la liste vide si aucun |> std::vector n'est passe.
Je n'avais pas saisi qu'il s'agissait d'un paramètre.
|> Quelle est la bonne solution dans ce cas et pourquoi la mienne est |> si "horrible" que ca? N'hesitez pas a detailler vos reponses car ca |> m'interesse de bien voir ce qu'il ne faut pas faire.
En cas d'un paramètre, ta solution est très bien, à condition de declarer la référence const. Si tu ne modifies pas le paramètre, ça marchera sans problème. Et si tu modifies le paramètre, je me poserais d'avantage de questions sur la conception de la classe.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
James Kanze
Fabien LE LEZ writes:
|> On 6 May 2004 23:42:17 -0700, wrote:
|> >Et avec const, je ne vois pas à quoi ça peut servir.
|> C'est à peu près la même chose que
|> class A |> { |> public: |> A (int parametre= 0); |> };
Sauf que dans le posting initial, il n'était pas question d'un paramètre. Ou au moins, il ne l'avait pas dit.
|> >> ... mais la signification est totalement différente (i.e. la |> >> fonction ne peut plus modifier le paramètre).
|> >Je ne dirais pas « totalement différente ».
|> Disons qu'un paramètre passé par référence constante est |> un paramètre "normal", i.e. une variable qui donne des |> informations à la fonction appelée, comme pour un passage par |> valeur.
|> Passer un paramètre en référence non constante, au |> contraire, indique (généralement) que la fonction va modifier |> le paramètre
Tu lis trop de livres:-). D'après mes expériences, passer un paramètre en référence non const signifie le plupart du temps que l'auteur ne connaît pas le const.
Le problème est en fait curieux. Ta caractèrisation est correcte pour le code bien conçu, en C++ : une référence non-const sert quand on veut un paramètre out ou inout ; une référence const est en revanche correspond plutôt une optimisation du passe par valeur, pour éviter une copie considérée chère. Et l'interdiction d'initialiser une référence non-const avec un temporaire n'est pas récente ; si mes souvenirs sont bons, CFront 2.1 émittait déjà un avertissement dans ce cas. C-à-d bien avant la plupart des programmeurs C++ d'aujourd'hui ont appris le langage.
N'empêche que je vois toujours énormement du code qui ignore le const.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Fabien LE LEZ <gramster@gramster.com> writes:
|> On 6 May 2004 23:42:17 -0700, kanze@gabi-soft.fr wrote:
|> >Et avec const, je ne vois pas à quoi ça peut servir.
|> C'est à peu près la même chose que
|> class A
|> {
|> public:
|> A (int parametre= 0);
|> };
Sauf que dans le posting initial, il n'était pas question d'un
paramètre. Ou au moins, il ne l'avait pas dit.
|> >> ... mais la signification est totalement différente (i.e. la
|> >> fonction ne peut plus modifier le paramètre).
|> >Je ne dirais pas « totalement différente ».
|> Disons qu'un paramètre passé par référence constante est
|> un paramètre "normal", i.e. une variable qui donne des
|> informations à la fonction appelée, comme pour un passage par
|> valeur.
|> Passer un paramètre en référence non constante, au
|> contraire, indique (généralement) que la fonction va modifier
|> le paramètre
Tu lis trop de livres:-). D'après mes expériences, passer un
paramètre en référence non const signifie le plupart du temps
que l'auteur ne connaît pas le const.
Le problème est en fait curieux. Ta caractèrisation est correcte
pour le code bien conçu, en C++ : une référence non-const sert
quand on veut un paramètre out ou inout ; une référence const
est en revanche correspond plutôt une optimisation du passe par
valeur, pour éviter une copie considérée chère. Et
l'interdiction d'initialiser une référence non-const avec un
temporaire n'est pas récente ; si mes souvenirs sont bons, CFront 2.1
émittait déjà un avertissement dans ce cas. C-à-d bien avant
la plupart des programmeurs C++ d'aujourd'hui ont appris le langage.
N'empêche que je vois toujours énormement du code qui ignore le
const.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> >> ... mais la signification est totalement différente (i.e. la |> >> fonction ne peut plus modifier le paramètre).
|> >Je ne dirais pas « totalement différente ».
|> Disons qu'un paramètre passé par référence constante est |> un paramètre "normal", i.e. une variable qui donne des |> informations à la fonction appelée, comme pour un passage par |> valeur.
|> Passer un paramètre en référence non constante, au |> contraire, indique (généralement) que la fonction va modifier |> le paramètre
Tu lis trop de livres:-). D'après mes expériences, passer un paramètre en référence non const signifie le plupart du temps que l'auteur ne connaît pas le const.
Le problème est en fait curieux. Ta caractèrisation est correcte pour le code bien conçu, en C++ : une référence non-const sert quand on veut un paramètre out ou inout ; une référence const est en revanche correspond plutôt une optimisation du passe par valeur, pour éviter une copie considérée chère. Et l'interdiction d'initialiser une référence non-const avec un temporaire n'est pas récente ; si mes souvenirs sont bons, CFront 2.1 émittait déjà un avertissement dans ce cas. C-à-d bien avant la plupart des programmeurs C++ d'aujourd'hui ont appris le langage.
N'empêche que je vois toujours énormement du code qui ignore le const.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Fabien LE LEZ
On 08 May 2004 21:07:20 +0200, James Kanze wrote:
Tu lis trop de livres:-). D'après mes expériences, passer un paramètre en référence non const signifie le plupart du temps que l'auteur ne connaît pas le const.
Mais dans ce cas, est-ce que ça vaut vraiment le coup de continuer à lire le code ?..
-- ;-) FLL, Epagneul Breton
On 08 May 2004 21:07:20 +0200, James Kanze <kanze@gabi-soft.fr> wrote:
Tu lis trop de livres:-). D'après mes expériences, passer un
paramètre en référence non const signifie le plupart du temps
que l'auteur ne connaît pas le const.
Mais dans ce cas, est-ce que ça vaut vraiment le coup de continuer à
lire le code ?..
Tu lis trop de livres:-). D'après mes expériences, passer un paramètre en référence non const signifie le plupart du temps que l'auteur ne connaît pas le const.
Mais dans ce cas, est-ce que ça vaut vraiment le coup de continuer à lire le code ?..
