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]

Kiuhnm wrote:

#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
--
I'm not just a number. To many, I'm known as a string...

[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]

Kiuhnm wrote:

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?

You can't.

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.

Not.

[Daniel T.]

In article <44***********************@reader1.news.tin.it>,
Kiuhnm <"kiuhnm03["@]yahoo.it> wrote:

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.

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?
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[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]

Kiuhnm" <"kiuhnm03[ wrote:

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
--
Please remove capital As from my address when replying by mail

[Dietmar Kuehl]

Kiuhnm wrote:

#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".
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence

[AnalogFile]

Dietmar Kuehl wrote:

Kiuhnm wrote:

#include <new>

class T
{
};

int main()
{
T t = t;
T u(u);
T v;
new (&v) T(v);
}
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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Rolf Magnus]

Kiuhnm wrote:

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:

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.

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:

* 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.

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

Formally, that's using it.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Rolf Magnus]

Kiuhnm wrote:

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.

[Kai-Uwe Bux]

Alf P. Steinbach wrote:

* 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.

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

[AnalogFile]

Alf P. Steinbach wrote:

* 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.

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.

[Alf P. Steinbach]

* Kai-Uwe Bux:

Alf P. Steinbach wrote:

* 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.

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.

§4.1/1 "... if the object is uninitialized, a program that necessitates
this conversion [to rvalue] has undefined behavior".

I don't think it ever was /meant/ to cover int values, but, it does.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alf P. Steinbach]

* AnalogFile:

Alf P. Steinbach wrote:

* 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.

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.

Now I just replied to the same question posted by Kai-Uwe... :-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[AnalogFile]

Kai-Uwe Bux wrote:

Alf P. Steinbach wrote:

* 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.

.... 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

No. "omits the description of any explicit definition of behavior" does
not cover indeterminate values.

int x;

creates and x with indeterminate value. But it's defined behavior.

You can even use the x.

int x;
cout << x;

writes a value to standard output. Not guarantees on what value, except
it's in the range of ints. It's defined behavior.

If it was undefined a compiler could power off your machine with that
code. But it is defined and the only thing a conforming compiler can do
is write a value to standard output.

[AnalogFile]

Rolf Magnus wrote:

Kiuhnm wrote:

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.

When the standard says: "this happens" it means that "this happens" is
the legal, defined, behavior. Undefined behavior is when the standard
says something is undefined or when it says nothing at all.

Also "indeterminate value" is a defined behavior for initialization in
many other cases.

[Kiuhnm]

Rolf Magnus ha scritto:

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.

I cannot believe a formal example contains illegal code (if not
specifically noted).
Anyway, where does the standard say that code is illegal?

Kiuhnm

[AnalogFile]

Alf P. Steinbach wrote:

* Kai-Uwe Bux:

Alf P. Steinbach wrote:

* 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.

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.

§4.1/1 "... if the object is uninitialized, a program that necessitates
this conversion [to rvalue] has undefined behavior".

I don't think it ever was /meant/ to cover int values, but, it does.

Does not apply. Quote the whole text!

"If the object to which the lvalue refers is not
an object of type T and is not an object of a type derived from T, or if
the object is uninitialized, a program
that necessitates this conversion has undefined behavior."

only if a conversion is required because the object is not already of
the required type, then the object must be initialized.

In

int x=x;

no conversion is required and that text does not apply.

[Alf P. Steinbach]

* AnalogFile:

Alf P. Steinbach wrote:

* Kai-Uwe Bux:

Alf P. Steinbach wrote:

* 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.

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.

§4.1/1 "... if the object is uninitialized, a program that
necessitates this conversion [to rvalue] has undefined behavior".

I don't think it ever was /meant/ to cover int values, but, it does.

Does not apply. Quote the whole text!

"If the object to which the lvalue refers is not
an object of type T and is not an object of a type derived from T, or if
the object is uninitialized, a program
that necessitates this conversion has undefined behavior."

only if a conversion is required because the object is not already of
the required type, then the object must be initialized.

No, sorry, that's just wishfulness on your part.

This paragraph mainly applies to conversion T -> T, where you have an
lvalue of type T and end up with an rvalue of type T.

There is a bit more, type-wise, regarding classes, but for primitive
types like int "the type of the rvalue is the cv-unqualified version of
T", i.e., the conversion is then cv T -> T for any cv-qualification.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Victor Bazarov]

AnalogFile wrote:

Rolf Magnus wrote:

Kiuhnm wrote:

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.

When the standard says: "this happens" it means that "this happens" is
the legal, defined, behavior.

None of what the Standard says in "Notes" or "Examples" is normative.
Undefined behavior is when the standard
says something is undefined or when it says nothing at all.

Also "indeterminate value" is a defined behavior for initialization in
many other cases.

Yes, but the fact that you need to _extract_ that value from an object
makes the behaviour undefined.

V
--
Please remove capital As from my address when replying by mail

[AnalogFile]

Victor Bazarov wrote:
....

Also "indeterminate value" is a defined behavior for initialization in
many other cases.

Yes, but the fact that you need to _extract_ that value from an object
makes the behaviour undefined.

If what you say was true, a conforming C++ compiler could translate the
following code:

#include <iostream>
int main()
{
int x;
std::cout << x;
}

to code that formats you disk.
I think it cannot.

And I see nowere in the standard any wording that says that extracting
an undetermined value from a POD is undefined. But I do find wordings
that say that extracting a value is defined and that initializing with
undetermined value is defined.

[peter koch]

AnalogFile wrote:

Victor Bazarov wrote:
...

Also "indeterminate value" is a defined behavior for initialization in
many other cases.

Yes, but the fact that you need to _extract_ that value from an object
makes the behaviour undefined.

If what you say was true, a conforming C++ compiler could translate the
following code:

#include <iostream>
int main()
{
int x;
std::cout << x;
}

to code that formats you disk.
I think it cannot.

And I see nowere in the standard any wording that says that extracting
an undetermined value from a POD is undefined. But I do find wordings
that say that extracting a value is defined and that initializing with
undetermined value is defined.

I believe that C++ in this case has inherited its behaviour from C.
Without wanting to be taken to serious, I believe that accessing
uninitialized storage in the form of char or unsigned integral types
should not be allowed to trap. Accessing it as other types (thus
including plain int) is allowed to trap.

/Peter

[Alf P. Steinbach]

* AnalogFile:

#include <iostream>
int main()
{
int x;
std::cout << x;
Error: use of possibly undefined operator<<.
Error: use of uninitialized variable.
}
[snip]
And I see nowere in the standard any wording that says that extracting
an undetermined value from a POD is undefined.
§4.1/1.

But I do find wordings
that say that extracting a value is defined and that initializing with
undetermined value is defined.

No, you don't.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?