«

Consider the following code:

struct C {
C(int i) : j(i) {}
int j;
};

int main() {
C c1(42);
C c = c = c1;
}

Does it have well-defined behaviour?

DP

On 12 Jun, 09:56, "Fred Zwarts" <F.Zwa...@KVI.nl> wrote:
> "Triple-DES" <DenPlettf...@gmail.com> wrote:
> > int main() {
> > *C c1(42);
> > *C c = c = c1;
> > }

> I think it is not a double assignment. It is initialization and assignment..
> C c = c = c1; can be rewritten as C c (c = c1),
> which makes clear that c is used as a parameter for its own construction.

Yes, a more suitable topic would be: copy-initialization and
assignment. It seems obvious that C c = c; is undefined. However I am
still not convinced about C c = (c = c1).

DP

Triple-DES <> writes:

> Consider the following code:
>
> struct C {
> C(int i) : j(i) {}
> int j;
> };
>
> int main() {
> C c1(42);
> C c = c = c1;
> }
>
> Does it have well-defined behaviour?

AFAIK, in your specific case, yes. However, the copy constructor
(implicit in this case) may be called as many times as you assign to
c. So if you had your own copy constructor, you would have to be
careful about side effects and order of member copying, etc.


--
__Pascal Bourguignon__

On Jun 12, 9:23 am, Triple-DES <DenPlettf...@gmail.com> wrote:
> Consider the following code:

> struct C {
> C(int i) : j(i) {}
> int j;
> };

> int main() {
> C c1(42);
> C c = c = c1;
> }

> Does it have well-defined behaviour?

Formally, I don't think so, since you're calling C:perator=
before having constructed C (and the constructor is not
trivial).

In practice, I don't think it matters, since I don't think you'd
ever want to do this anyway.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Triple-DES wrote:
> Consider the following code:
>
> struct C {
> C(int i) : j(i) {}
> int j;
> };
>
> int main() {
> C c1(42);
> C c = c = c1;
> }
>
> Does it have well-defined behaviour?
>
> DP
The real question is,
WHY!?!!?
It seems likely to be a programmer error, and the meaning is very much
*not* intuitive. If you have to spend that much time worrying about
whether its well-defined, and what its defined behavior is, then you
should consider a different idiom that is more intuitive for human readers.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>