Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C++ question sur le temps d'execution des operateurs

question sur le temps d'execution des operateurs

12 réponses
Avatar
Fred
j'ai vu qu'il etait coutume de definir les operateurs avec une valeur de
retour, meme pour certains operateurs ou cela n'etait pas forcement tres
utile.

example

const MonType& operator=(conts MonType& maValeur);

alors que l'on peut aussi faire

void operator=(conts MonType& maValeur);

Donc

Mes questions :

si on fait juste "a=b;" y a t'il une difference dans le temps d'execution
des 2 operateurs?

si on fait "a=b=c=d=e=f=g;" y a t'il une difference entre les 2 operateurs?

qui est "le plus fort"
f=g;
e=f;
d=e;
c=d;
d=b;
a=b;

ou
a=b=c=d=e=f=g;

ou est-ce que cela n'apporte juste qu'une souplesse dans l'ecriture?

Fred
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
1 2
Avatar
Jean-Marc Bourguet
"Fred" writes:

const MonType& operator=(conts MonType& maValeur);

void operator=(conts MonType& maValeur);

si on fait juste "a=b;" y a t'il une difference dans le temps d'execution
des 2 operateurs?


Faut mesurer. Rien d'important a priori.

si on fait "a=b=c=d=e=f=g;" y a t'il une difference entre les 2 operateurs?


Le deuxieme n'est pas permis.

qui est "le plus fort"


Qu'entends-tu par "le plus fort"?

On rencontre aussi

MonType& operator=(MonType const&);

qui a l'avantage d'etre celle utilisee quand c'est le compilateur qui
la genere.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Avatar
Benoit Dejean
Le Tue, 01 Jul 2003 10:51:38 +0200, Vincent Richard a ecrit:


j'ai vu qu'il etait coutume de definir les operateurs avec une valeur
de retour, meme pour certains operateurs ou cela n'etait pas forcement
tres utile.

example

const MonType& operator=(conts MonType& maValeur);




La fonction correcte est la 1ère (sans le "const" en valeur de retour
!).


ou est le problème? moi il me semble que le const permet de garder un peu
de lisibilité et d'eviter les confusions...

class Foo
{
public:
const Foo & operator=(const Foo &other) {
return *this;
}

void f() const
{}

void g()
{}
};


int main()
{
Foo a, b,c;

a=b;
a=b=c;

// on peut pas dire que ça soit une tres bonne pratique :oD
(a=b=c).f();
(a=b=c).g();
}


--
Ne perdez pas de vue qu'un programme qui plante est d'une utilité quasi nulle,
ce qui est loin d'être incompatible avec la notion d'Art.


Avatar
Christophe Lephay
"Jean-Marc Bourguet" a écrit dans le message de
news:
On rencontre aussi

MonType& operator=(MonType const&);

qui a l'avantage d'etre celle utilisee quand c'est le compilateur qui
la genere.


Euh, tu pourrais expliquer un peu ou reformuler, stp (je comprends pas très
bien ta phrase) ?

Chris

Avatar
Fabien LE LEZ
On Tue, 01 Jul 2003 12:19:49 +0200, Benoit Dejean
wrote:

const MonType& operator=(conts MonType& maValeur);




La fonction correcte est la 1ère (sans le "const" en valeur de retour
!).


ou est le problème? moi il me semble que le const permet de garder un peu
de lisibilité et d'eviter les confusions...


Avec le const, a=b=c devient interdit.


--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html



Avatar
kanze
Benoit Dejean wrote in message
news:...
Le Tue, 01 Jul 2003 10:51:38 +0200, Vincent Richard a ecrit:


j'ai vu qu'il etait coutume de definir les operateurs avec une
valeur de retour, meme pour certains operateurs ou cela n'etait pas
forcement tres utile.

example

const MonType& operator=(conts MonType& maValeur);


La fonction correcte est la 1ère (sans le "const" en valeur de
retour !).


ou est le problème? moi il me semble que le const permet de garder un
peu de lisibilité et d'eviter les confusions...

class Foo
{
public:
const Foo & operator=(const Foo &other) {
return *this;
}

void f() const
{}

void g()
{}
};

int main()
{
Foo a, b,c;

a=b;
a=b=c;

// on peut pas dire que ça soit une tres bonne pratique :oD
(a=b=c).f();
(a=b=c).g();
}


De principe et par goût, je suis d'accord avec toi. Mais le langage
permet des choses comme :

int a ;

int&
f()
{
return a = 1 ;
}

Alors, le principe du moindre surprise veut que tes classes à toi le
permet aussi.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16



Avatar
kanze
Vincent Richard wrote
in message news:<3f014b9b$0$12450$...

j'ai vu qu'il etait coutume de definir les operateurs avec une
valeur de retour, meme pour certains operateurs ou cela n'etait pas
forcement tres utile.

example

const MonType& operator=(conts MonType& maValeur);

alors que l'on peut aussi faire

void operator=(conts MonType& maValeur);


La fonction correcte est la 1ère (sans le "const" en valeur de retour
!). Je ne sais pas si la 2ème est valide, ni même si elle est "légale"
(point de vue norme).


Pourquoi ne serait-elle pas permise ? La norme te laisse toute la
liberté de définir ton operator= comme tu veux. (Considère le cas d'un
proxy, par exemple, où l'opérateur = est en général une fonction const.)

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16


Avatar
Vincent Richard

On Tue, 01 Jul 2003 12:19:49 +0200, Benoit Dejean
wrote:

const MonType& operator=(conts MonType& maValeur);




La fonction correcte est la 1ère (sans le "const" en valeur de retour
!).


ou est le problème? moi il me semble que le const permet de garder un peu
de lisibilité et d'eviter les confusions...


Avec le const, a=b=c devient interdit.


C'est à ça que j'ai pensé au moment d'écrire ma réponse, mais après
réflexion, il me semble que la valeur de retour devient le membre droit
de l'opérateur = suivant, non ?

Pour a = b = c :

b = c ==> renvoie const& b
a = (b = c) ==> OK, que (b = c) soit const ou non

Vincent

--
SL> Au fait elle est mieux ma signature maintenant ?
Oui. T'enlève encore les conneries que t'as écrit dedans et c'est bon.
-+- JB in <http://www.le-gnu.net> : Le neuneuttoyage par le vide -+-




Avatar
Fabien LE LEZ
On Tue, 01 Jul 2003 16:56:37 +0200, Fabien LE LEZ
wrote:

ou est le problème? moi il me semble que le const permet de garder un peu
de lisibilité et d'eviter les confusions...


Avec le const, a=b=c devient interdit.


En fait je me suis emmêlé les pinceaux. C'est (a=b)=c qui devient
interdit. Et évidemment, pour le coup, l'intérêt ne saute pas aux
yeux...

Il y a quand même une bonne raison de renvoyer un non-const : avec un
opérateur avec la même signature que celui que le compilo aurait
pondu...


--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html


Avatar
ballombert
Bonjour,

const MonType& operator=(conts MonType& maValeur);


La fonction correcte est la 1ère (sans le "const" en valeur de retour
!).


ou est le problème? moi il me semble que le const permet de garder un peu
de lisibilité et d'eviter les confusions...


Ci-dessous un problème soulevé par Bruce Eckel, Effective C++/Item 15
:

Another common error is to have operator= return a reference to a
const object, like this:

class Widget {
public:
... // note
const Widget& operator=(const Widget& rhs); // const
... // return
}; // type

The usual motivation is to prevent clients from doing silly things
like this:

Widget w1, w2, w3;
...
(w1 = w2) = w3; // assign w2 to w1, then w3 to
// the result! (Giving Widget's
// operator= a const return value
// prevents this from compiling.)

Silly this may be, but not so silly that it's prohibited for the
built-in types:

int i1, i2, i3;
...
(i1 = i2) = i3; // legal! assigns i2 to
// i1, then i3 to i1!

I know of no practical use for this kind of thing, but if it's good
enough for the ints, it's good enough for me and my classes. It should
be good enough for you and yours, too. Why introduce gratuitous
incompatibilities with the conventions followed by the built-in types?



Avatar
kanze
(Bertrand Allombert-Blanc) wrote in message
news:...

const MonType& operator=(conts MonType& maValeur);


La fonction correcte est la 1ère (sans le "const" en valeur de
retour !).


ou est le problème? moi il me semble que le const permet de garder
un peu de lisibilité et d'eviter les confusions...


Ci-dessous un problème soulevé par Bruce Eckel, Effective C++/Item 15
:

Another common error is to have operator= return a reference to a
const object, like this:


Il y va fort, en l'appelant une erreur. On peut préférer la version
non-const, mais un retour d'une référence const n'est certainement pas
une erreur non plus.

class Widget {
public:
... // note
const Widget& operator=(const Widget& rhs); // const
... // return
}; // type

The usual motivation is to prevent clients from doing silly things
like this:

Widget w1, w2, w3;
...
(w1 = w2) = w3; // assign w2 to w1, then w3 to
// the result! (Giving Widget's
// operator= a const return value
// prevents this from compiling.)

Silly this may be, but not so silly that it's prohibited for the
built-in types:

int i1, i2, i3;
...
(i1 = i2) = i3; // legal! assigns i2 to
// i1, then i3 to i1!


Et il se trompe. C'est interdit. La seule différence, c'est que le
compilateur n'est pas obligé à signaler l'erreur -- c'est un
comportement indéfini.

I know of no practical use for this kind of thing, but if it's good
enough for the ints, it's good enough for me and my classes. It should
be good enough for you and yours, too. Why introduce gratuitous
incompatibilities with the conventions followed by the built-in types?


L'exemple qu'on m'a cité, c'est celui que j'ai déjà posté. Qui ne me
convainc pas vraiment -- il est nettement préférable à utiliser deux
instructions dans ce cas-là. Mais dans l'ensemble, le principe de la
moindre surprise semble emporter, pour moi. Mais c'est à la limite, et
si d'autres préfèrent une référence const, je ne vais pas les critiquer
pour ça.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16




1 2