Is the following code legal?

[Kiuhnm]

#include <new>

class T
{
};

int main()
{
T t = t;
T u(u);
T v;
new (&v) T(v);
}

Kiuhnm

 

[Ben Pope]

#include <new>

class T
{
};

int main()
{
T t = t;
T u(u);
T v;
new (&v) T(v);
}

Kiuhnm

Have you tried compiling this?

Does you compiler give you errors?

Why do you think that is?

What do you expect each line to do?

Ben Pope

 

[Kiuhnm]

Ben Pope ha scritto:

Have you tried compiling this?

Yes, but it is irrelevant. How can I be sure that my compiler is
completely standard-compliant?

What do you expect each line to do?

It is irrelevant.
All I would like to know is whether the code, according to the standard,
produces a defined behavior or not.

Kiuhnm

 

[Rolf Magnus]

Ben Pope ha scritto:

Yes, but it is irrelevant. How can I be sure that my compiler is
completely standard-compliant?

You can't.

It is irrelevant.
All I would like to know is whether the code, according to the standard,
produces a defined behavior or not.

Not.

 

[Daniel T.]

Ben Pope ha scritto:

Yes, but it is irrelevant. How can I be sure that my compiler is
completely standard-compliant?


It is irrelevant.
All I would like to know is whether the code, according to the standard,
produces a defined behavior or not.

T t = t;
T u(u);

The above two lines will compile but the behavior is undefined.


T v;
new (&v) T(v);

The above two lines produce defined behavior.

Please, why do you ask?

 

[Kiuhnm]

Rolf Magnus ha scritto:

Not.

Why?
I read 3.3.1 and 3.8 in the c++ iso, but that did not clarify my doubts.

Kiuhnm

 

[Kiuhnm]

Daniel T. ha scritto:

T t = t;
T u(u);

The above two lines will compile but the behavior is undefined.

And what about
int x = x;
?

Please, why do you ask?

I am just curious.

Kiuhnm

 

[Victor Bazarov]

Daniel T. ha scritto:

T t = t;
T u(u);

The above two lines will compile but the behavior is undefined.

And what about
int x = x;
?

What's the difference from

T t = t;

do you see here?

V

 

[Dietmar Kuehl]

#include <new>

class T
{
};

int main()
{
T t = t;
T u(u);
T v;
new (&v) T(v);
}

What is your particular question anyway? What do you suspect to be
illegal and why? The obvious violation is double construction of an
object which is illegal. However, you put other stuff into the
article, too, which might indicate that you are actually looking for
other sources of "illegal code".

 

[AnalogFile]

What is your particular question anyway?

He is asking because we have been discussing that in our national C++
newsgroup but did not come to a definitive conclusion.

There are more variations on the same theme and they may or may not
change the validity of those constructs.

What do you suspect to be
illegal and why?

It depends who you ask to. If we had any consensus we would not even ask.

For as much as we can say the placement new construct is perfectly defined.

That is:

void foo()
{
class T {} v;
new (&v) T(v);
}

is perfectly legal.

The obvious violation is double construction of an
object which is illegal.

Not. The standard does not say you cannot construct twice. And does not
guarantee that the number of constructions matches the number of
destructions. If you reuse the memory of a live object, that object
lifetime ends without the construction being called and it is explicitly
legal to do so. See 3.8#4

However, you put other stuff into the
article, too, which might indicate that you are actually looking for
other sources of "illegal code".

In fact 3.8 is no help in the other cases.

We know that

struct T {
void *p;
T(){}
T(T*pp){ p=pp; if (pp==this) cout << "wow!\n"; }
};

void foo()
{
T t=&t;
T u(&u);
}

is perfectly defined (see 3.3.1#1 and 3.8#5)

But the wording in 3.8, specifically the first item of the list in
3.8#5, together with 3.8#1 seem to imply that

struct T {
int i;
T(){}
T(const T&r){i=r.i;}
};

void foo()
{
T t=t;
T u(u);
}

is undefined behavior (cannot access r.i until the lifetime has begun,
and that happens at the end of the constructor).

And this is apparently incongruous with the fact that

void foo()
{
int i=i;
int j(j);
}

is perfectly valid as in 3.3.1#1

 

[Kiuhnm]

Victor Bazarov ha scritto:

What's the difference from

T t = t;

do you see here?

T may not be a built-in type.

Anyway, my question was subtler than you think:
excerpt from c++ iso/iec 14882:3.3.1 Point of declaration

The /point of declaration/ for a name is immediately after its complete
declarator (clause 8) and before its /initializer/ (if any), except as
noted below.
[Example:

int x = 12;
{ int x = x; }

Here the second x is initialized with its own (indeterminate) value.]
<<<

Then "int x = x;" is /not/ undefined (e.g. a standard-compliant compiler
cannot format your hard disk).

Kiuhnm

 

[Alf P. Steinbach]

* Kiuhnm:

Then "int x = x;" is /not/ undefined (e.g. a standard-compliant compiler
cannot format your hard disk).

Using an indeterminate value, for anything, is formally UB.

 

[Rolf Magnus]

Victor Bazarov ha scritto:

What's the difference from

T t = t;

do you see here?

T may not be a built-in type.

Anyway, my question was subtler than you think:
excerpt from c++ iso/iec 14882:3.3.1 Point of declaration

The /point of declaration/ for a name is immediately after its complete
declarator (clause 8) and before its /initializer/ (if any), except as
noted below.
[Example:

int x = 12;
{ int x = x; }

Here the second x is initialized with its own (indeterminate) value.]
<<<

Then "int x = x;" is /not/ undefined (e.g. a standard-compliant compiler
cannot format your hard disk).

It doesn't say that. It just says that, when the right hand side is
evaluated, the name 'x' already exists. It doesn't say anything about the
behavior of initializing x with an indeterminate value.

 

[Kiuhnm]

Rolf Magnus ha scritto:

It doesn't say that. It just says that, when the right hand side is
evaluated, the name 'x' already exists. It doesn't say anything about the
behavior of initializing x with an indeterminate value.

3.3.1#1:
"[...]Here the second x is initialized with its own (indeterminate) value."

Kiuhnm

 

[Kiuhnm]

Alf P. Steinbach ha scritto:

* Kiuhnm:



Using an indeterminate value, for anything, is formally UB.

I am just copying it (we cannot overload operator= for built-in types).

Kiuhnm

 

[Kiuhnm]

Kiuhnm ha scritto:

I am just copying it (we cannot overload operator= for built-in types).

Please, forget "overload". I meant "provide a user-defined".

Kiuhnm

 

[Alf P. Steinbach]

* Kiuhnm:

Alf P. Steinbach ha scritto:

I am just copying it (we cannot overload operator= for built-in types).

Formally, that's using it.

 

[Kai-Uwe Bux]

* Kiuhnm:

Using an indeterminate value, for anything, is formally UB.

I did a search for "indeterminate" in my electronic version of the standard,
and I did not find a statement to that extend. I would be grateful for
chapter and verse.

It appears that almost all uses (and most definitely all interesting uses)
of indeterminate values lead to undefined behavior per the catch all clause
in [1.3.12]: "Undefined behavior may also be expected when this
International Standard omits the description of any explicit definition of
behavior." However, one could argue that in the case of

int x = x;

the standard actually provides an explicit definition of behavior, namely
that the variable x is initialized in such a way that its value after
initialization is undefined.


Best

Kai-Uwe Bux

 

[Rolf Magnus]

Rolf Magnus ha scritto:

It doesn't say that. It just says that, when the right hand side is
evaluated, the name 'x' already exists. It doesn't say anything about the
behavior of initializing x with an indeterminate value.

3.3.1#1:
"[...]Here the second x is initialized with its own (indeterminate)
value."

And again, it doesn't say that initializing it with an indeterminate value
is legal, just that it is done here, because x is known before it is
initializied, so the name can be used for the initializer.

 

[AnalogFile]

* Kiuhnm:

Using an indeterminate value, for anything, is formally UB.

Can you point me to where in the standard it says so?

AFAIK it is defined behavior (with indeterminate result) for every POD
type except when dereferencing a pointer.