class object initialisation

[Kevin Goodsell]

I do not care if a later "giving of a correct value" is called assignment
and not initialization. Just be brave and admit that it is legal to have
uninitialized PODs around

In the sense that the word is usually used, yes. But it's very clear
that the standard (and the people who wrote it) consider
"initialization" to be something that occurs when the object is created.
I suppose you can debate whether or not it *always* occurs when an
object is created, but that's not really relevant to how the language is
used. The most important point is that initialization cannot happen at
some later time. Assignment can, and then the object is considered, for
all intents and purposes, initialized, and usable as an rvalue.

The only part of this debate that is important at all is the fact that
initialization and assignment are different, and mutually exclusive.

(as long as they are not used as an rvalue) and
that it is legal to assign a value to an uninitialized POD, which makes it
initialized. PODs can be initialized "later" than their
definition/construction.

But it's not initialization in the sense that the standard uses it. It
is (pseudo-)initialization in the sense that the object is not longer
considered "uninitialized" (which actually means "indeterminate" in the
common use).

The initialization (giving a correct initial value
and thereby forming a valid POD type T) can be done using an assigment.

I don't know why we are still debating this when the standard is so
clear on it. Show me anywhere in the standard where it is even suggested
that assignment can constitute initialization.

-Kevin

 

[Kevin Goodsell]

Appeal to authority is a very very weak argument.

So we can't appeal to the standard and the people who wrote it when
discussing the language they defined?

Especially when that authority himself have used the word in its common
and very much broader meaning, e.g. in the appendix on exception safety
in 3rd ed. of TCPPPL...

So has the standard. It's considered a defect. Stroustrup isn't perfect,
and even if he were his intent in that book is to present the language
in a usable way, not to duplicate the standard. So he uses non-standard
terminology from time to time. But the definition of "initialization"
from his glossary is consistent with the standard.

The terminology you suggest is very unfortunate, both because it does
not reflect established usage, and because adopting that terminology
would require some new word to refer what's known as initialization.

E.g., in the FAQ the word "initialization" is used to refer to any
initialization whether it occurs during C++ constructor execution or
not, whereas "construction" seems to be reserved for C++ constructor
execution.

This is technically an error in the FAQ, but it makes so little
difference that it hardly matters. The only problem with it is that it
leads to discussions like this one. The common usage is technically
incorrect, but rarely harmful.

-Kevin

 

[Alf P. Steinbach]

So we can't appeal to the standard and the people who wrote it when
discussing the language they defined?

Those two questions concern a very different matter than redefining
a common term.

The answer to the first is yes, you can.

The answer to the second is yes, you can, but of limited value.

...
The common usage is technically incorrect, but rarely harmful.

Reminds me of Jim Carrey bashing himself in the toilet. ;-)

 

[Kevin Goodsell]

Those two questions concern a very different matter than redefining
a common term.

I never suggested that.

The answer to the first is yes, you can.

The answer to the second is yes, you can, but of limited value.

(If I understand you correctly...)

The people that wrote the standard are the only ones who can properly
describe the intent in some cases.

-Kevin

 

[Alf P. Steinbach]

I never suggested that.

I thought you did. Hum, well, tracking back up the thread I failed to
see what's really being discussed. Except that calling a non-initialization
initialization is one issue, and there I side with Attila: it's of negative
value to dilute and change a common term by using it for its opposite.

(If I understand you correctly...)

The people that wrote the standard are the only ones who can properly
describe the intent in some cases.

Is that the case here?

 

[Kevin Goodsell]

I thought you did. Hum, well, tracking back up the thread I failed to
see what's really being discussed. Except that calling a non-initialization
initialization is one issue, and there I side with Attila: it's of negative
value to dilute and change a common term by using it for its opposite.

I certainly can't deny that, in the past, assigning after the fact to an
object that was declared without an initializer has been considered to
"initialize" it. It does remove the "uninitialized" (or "indeterminate")
status from the object. But in the C++ standard terminology,
"initialization" is considered to be what is done by, e.g., constructors.

Is that the case here?

Could be. If there were an explicit definition for any of the terms
"initialization", "initialize", "uninitialized", etc. then it would be
more clear. I can't find any such definitions though, so I have to
consider the contexts in which the terms are used instead. Based on the
context, the intent would seem to be what I've been claiming (though
maybe not the part about all objects being initialized at declaration,
even without an initializer or appropriate default constructor - I'm not
so sure about that). However, my interpretation of the intent could be
incorrect. So it may be necessary to defer to someone who is in a
position to state what the intent actually was, rather than what is
appears to be.

-Kevin

 

[Alf P. Steinbach]

I certainly can't deny that, in the past, assigning after the fact to an
object that was declared without an initializer has been considered to
"initialize" it. It does remove the "uninitialized" (or "indeterminate")
status from the object. But in the C++ standard terminology,
"initialization" is considered to be what is done by, e.g., constructors.

Well, it so happens that e.g. §27.4.4.1/2 says, about the std::basic_ios
default constructor:

<quote>
Constructs an object of class basic_ios ... leaving its members

_uninitialized_.

The object must be

_initialized_

by calling its init member function. If it is destroyed before
it has been

_initialized_

the behavior is undefined.
</quote>

I think it's very simple: the words are used in various contexts, where
the meaning is (generally) clear. The basic meaning is the one in common
use of the term: an act of assigning values after allocation, properly
generalized to include the case of e.g. just assigning a zero value to
the length field of a string implementation, leaving the rest as-is. In
some contexts "initialize" clearly refers to language mechanisms that couple
initialization with allocation, in other cases, as above, initialization
is de-coupled from allocation -- not a technique I recommend, though.

Could be. If there were an explicit definition for any of the terms
"initialization", "initialize", "uninitialized", etc. then it would be
more clear. I can't find any such definitions though, so I have to
consider the contexts in which the terms are used instead. Based on the
context, the intent would seem to be what I've been claiming

See above.

 

[White Wolf]

So we can't appeal to the standard and the people who wrote it when
discussing the language they defined?

You have appealed to Bjarne, not to the standard.

So has the standard. It's considered a defect. Stroustrup isn't
perfect, and even if he were his intent in that book is to present
the language in a usable way, not to duplicate the standard. So he
uses non-standard terminology from time to time. But the definition
of "initialization" from his glossary is consistent with the standard.

And it is still wrong.

This is technically an error in the FAQ, but it makes so little
difference that it hardly matters. The only problem with it is that it
leads to discussions like this one. The common usage is technically
incorrect, but rarely harmful.

Except that it takes hours, instead of minutes, to make someone understand
that by "initialized to an undeterminate value" the standard means "not
initialized at all". Especially because the former in itself is a lie. If
the object cannot be read/understood as type T (like int) it does not have a
value. It is not an int yet, so speaking about its value is meaningless.

 

[White Wolf]

Kevin Goodsell wrote:
[SNIP]

The people that wrote the standard are the only ones who can properly
describe the intent in some cases.

Then the wording of the standard (in those cases) is weak. I mean C++ is
complicated enough without making its standard hard to understand.

 

[White Wolf]

In the sense that the word is usually used, yes. But it's very clear
that the standard (and the people who wrote it) consider
"initialization" to be something that occurs when the object is
created.

Except when not. Read Alf's post with his quote from the standard library
docs, where the standard definitely says that a constructor "leaves members
uninitialized". And the "initialization is done later".

I suppose you can debate whether or not it *always* occurs when an
object is created, but that's not really relevant to how the language
is used. The most important point is that initialization cannot
happen at some later time.

You can write it down to 101 standards, it still *does* happen later. If
you get an auto bool it is *not* a bool if you do not give it an initializer
until you assing a bool value to it later. If it is not a bool, then it is
definitely not initialized. PODs can be initialized later. Otherwise CPUs
would need to support constructors.

Assignment can, and then the object is considered,
for all intents and purposes, initialized, and usable as an rvalue.

In other words: initialized.

The only part of this debate that is important at all is the fact that
initialization and assignment are different, and mutually exclusive.

No, in case of PODs they are not very different and mutually exclusive:

int i =1; does exaclty the same as
int i;
i=1;

But it's not initialization in the sense that the standard uses it.

My point is that the standard uses the word incorrectly. So it would help
not repeating it forever that the standard uses it. So what? Even I made
mistakes. It was long time ago, but I did. ;-))

It
is (pseudo-)initialization in the sense that the object is not longer
considered "uninitialized" (which actually means "indeterminate" in
the common use).

Nope. It is initialization. Not syntax-wise maybe not C++ semantics-wise
as the standard defined it, but it is initialization. It gives the POD
object its first value. That is called initialization.

I don't know why we are still debating this when the standard is so
clear on it.

Because something wrong clearly said is still wrong. And I care about logic
and not about authority.

Show me anywhere in the standard where it is even
suggested that assignment can constitute initialization.

I do not give a damn if it is done or not. Just because it has ISO or ANSI
on it it is not a Holy Book from God. This is an error. Those - who wrote
that part - wanted to make a very very clear difference between
initialization and assignment. In case of non-const POD types there is no
such difference. So they came up with a hard-to-get clouding statement
which finally says: if you did not initialize a POD it is not yet
initialized. You can initialize it using assignment later.

 

[Kevin Goodsell]

Kevin Goodsell wrote:
[SNIP]

The people that wrote the standard are the only ones who can properly
describe the intent in some cases.

Then the wording of the standard (in those cases) is weak. I mean C++ is
complicated enough without making its standard hard to understand.

I agree. But it happens.

-Kevin

 

[tom_usenet]

Well, it so happens that e.g. §27.4.4.1/2 says, about the std::basic_ios
default constructor:

<quote>
Constructs an object of class basic_ios ... leaving its members

_uninitialized_.

The object must be

_initialized_

by calling its init member function. If it is destroyed before
it has been

_initialized_

the behavior is undefined.
</quote>

I think this highlights the weakness of the standard's use of
"initialize". Because it has attempted to change the meaning of the
word from the common programming one, the standard itself has become
internally inconsistent, since not everyone was aware of this new
special C++ meaning. There are several other places where this
"mistake" has been made with initialize.

Still, I think the intent of the standard is clear in all the places
discussed, whichever meaning of initialized it is using at that place,
so it isn't a major problem.

Tom

 

[Attila Feher]

tom_usenet wrote:
[SNIP]

I think this highlights the weakness of the standard's use of
"initialize". Because it has attempted to change the meaning of the
word from the common programming one, the standard itself has become
internally inconsistent, since not everyone was aware of this new
special C++ meaning. There are several other places where this
"mistake" has been made with initialize.

I think otherwise. The standard seems to mix up the two completely separate
concepts of initializer (syntax/semantics issue of a language element,
needed to be introduced because of the different between a constructor call
and an assignment operator call) and the act of initialization. These are
separate concepts, and that mistake shows up its ugly head when using PODs
(having no constructors):

int i = 0;

Initializer by the language semantics. Initialization by the act.

int i;

for (i = 0;...

Assignment by the language semantics. Initialization by the act.

 

[Alf P. Steinbach]

I think this highlights the weakness of the standard's use of
"initialize". Because it has attempted to change the meaning of the
word from the common programming one, the standard itself has become
internally inconsistent,

I disagree. After skimming the standard I've yet to see one instance
where e.g. "initialize" is used in a meaning that differs from the
common one. In many cases it's used in a _restricted_ contextual
meaning, and that is also consistent with the common multi-level usage.

since not everyone was aware of this new special C++ meaning.

What would "this" special meaning be? I think for any quote you might
come up with that apparently (out of context) supports one such special
meaning, another quote supports another. The standard does not define
the meaning precisely _because_, to most experienced people, the meaning
is obvious and not restricted to some special contextual narrowing.

There are several other places where this "mistake" has been made with
initialize.

You don't say... ;-)

Still, I think the intent of the standard is clear in all the places
discussed

It is.

whichever meaning of initialized it is using at that place,
so it isn't a major problem.

Right.

 

[tom_usenet]

tom_usenet wrote:
[SNIP]

If you choose your words carefully it makes more sense: "If we don't
provide an initializer for a POD, the object is initialized to an
indeterminate value."


Initialization == giving an initial value

not giving an initial value (but leave garbage there) !=
initialization

There is an inconsistency both in the common jargon and the standard
itself. We often say an object which has been created without an
initializer is "uninitialized". I don't believe this is correct. I'm
with Tom here. The correct term is "indeterminate".

Nope. An initialized object of any kind *might* contain an indeterminate
value (like initialized by rand()) but it contains a value which is in the
value set of the type for that object (object in C sense). Uninitialized
(auto) PODs do not fullfill this requirement. If something is not
initialized and it might not even be of its own type is uninitialized.

Being initialized by rand doesn't make something indeterminate, since
you can examine its value and hence find out what it is. Indeterminate
means that you cannot determine the value, not that you don't know the
value.

Perhaps a better term would be "singular", as used with iterators. So,
the standard would say: "An automatic storage POD that does not have
an explicit initializer is implicitly initialized to a singular
value." or similar, with a description of singular meaning
indeterminate, illegal in lvalue-to-rvalue conversions, etc. Makes
sense in C++ abstract machine terms, if not entirely in real world
terms.

I do not care if a later "giving of a correct value" is called assignment
and not initialization. Just be brave and admit that it is legal to have
uninitialized PODs around (as long as they are not used as an rvalue) and
that it is legal to assign a value to an uninitialized POD, which makes it
initialized. PODs can be initialized "later" than their
definition/construction. The initialization (giving a correct initial value
and thereby forming a valid POD type T) can be done using an assigment.

There are even more catches to this.

unsigned char c;
c = c; //legal!

unsigned char can never have indeterminate values (because all bits of
the object representation take part in the value representation).

The existence of PODs in the standard has created a bit of a legalese
headache. It is clear though that in order for initialization of
non-PODs to mean the same initialization of PODs, the concept of
indeterminate but initialized values has to be introduced. This is
useful elsewhere though: invalid pointers do have indeterminate
values, according to the note in 5.3.5/4. So, the standard text for
what you can't do with certain POD objects can't use the term
"uninitialized" but must use "indeterminate" or perhaps "singular". Is
it really useful to talk about uninitialized PODs then, rather than
ones with indeterminate values?

Tom

 

[Attila Feher]

Being initialized by rand doesn't make something indeterminate, since
you can examine its value and hence find out what it is. Indeterminate
means that you cannot determine the value, not that you don't know the
value.

Well, in my poor English vocabulary that is non-determinable. Indeterminate
is (for me) something we do not know for sure (like what will rand put
there) but we can find out later. Non-determinable is OTOH something which
cannot be examined.

But this whole point is mute: that very POD may not even conform to its own
requirements. The "value" there is *not* necessarily a value for that type,
hence it is not initialized.

Perhaps a better term would be "singular", as used with iterators. So,
the standard would say: "An automatic storage POD that does not have
an explicit initializer is implicitly initialized to a singular
value." or similar, with a description of singular meaning
indeterminate, illegal in lvalue-to-rvalue conversions, etc. Makes
sense in C++ abstract machine terms, if not entirely in real world
terms.

I dunno much about that abstract machine, but IMHO it makes much more sense
to say that it is not initialized. Because that is what happens. It is
assigned memory (it will become existing as an object - in the C meaning)
but it is not initialized.

There are even more catches to this.

unsigned char c;
c = c; //legal!

unsigned char can never have indeterminate values (because all bits of
the object representation take part in the value representation).

Where is that required by the standard?

The existence of PODs in the standard has created a bit of a legalese
headache. It is clear though that in order for initialization of
non-PODs to mean the same initialization of PODs, the concept of
indeterminate but initialized values has to be introduced.

The standard seems to mix existing with initialized...

This is
useful elsewhere though: invalid pointers do have indeterminate
values, according to the note in 5.3.5/4.

Again a bit of a mystery. delete take a *copy* of the pointer. So it
cannot change it at all. So the value of the pointer *is* determined, we
exactly know what value it has. Only this value is not to be dereferenced.

So, the standard text for what you can't do with
certain POD objects can't use the term
"uninitialized" but must use "indeterminate" or perhaps "singular".

Singular I like. Let's bet on this one. It is stunning enough that I
will stop seeing things like this in code:

zzz f2( bool &b, YYY y) {
if (y.w() != 32) return;
...
}

XXX f(YYY y) {
bool b;
ZZZ z = f2(b, y);
if (b) {
...
} else {
...
}
}

Is it really useful to talk about uninitialized
PODs then, rather than ones with indeterminate values?

Yes. "Indeterminate value" implies: it is an int, but with some garbage
value in it; while the truth is: it is a place for an int, with no int in
it.

 

[Alexander Terekhov]

Attila Feher wrote:
[...]

Indeterminate is ...

"either an unspecified value or a trap representation"

"unspecified value

valid value of the relevant type where this International
Standard imposes no requirements on which value is chosen
in any instance

NOTE An unspecified value cannot be a trap representation."

"Certain object representations need not represent a value
of the object type. If the stored value of an object has
such a representation and is read by an lvalue expression
that does not have character type, the behavior is
undefined. If such a representation is produced by a side
effect that modifies all or any part of the object by an
lvalue expression that does not have character type, the
behavior is undefined***41). Such a representation is
called a trap representation.
....
41) Thus, an automatic variable can be initialized to a
trap representation without causing undefined behavior,
but the value of the variable cannot be used until a
proper value is stored in it."

C "legacy", my friend. ;-)

regards,
alexander.

 

[Attila Feher]

Alexander Terekhov wrote:
[SNIP]

41) Thus, an automatic variable can be initialized to a
trap representation without causing undefined behavior,
but the value of the variable cannot be used until a
proper value is stored in it."

C "legacy", my friend. ;-)

It is still only a funny way to say: there is memory dedicated to that
variable (storage dedicated to that object) but that memory is uninitialized
therefore it may not represent a valid value for the given type.

 

[Gary Labowitz]

tom_usenet wrote:
[SNIP]

I think this highlights the weakness of the standard's use of
"initialize". Because it has attempted to change the meaning of the
word from the common programming one, the standard itself has become
internally inconsistent, since not everyone was aware of this new
special C++ meaning. There are several other places where this
"mistake" has been made with initialize.

I think otherwise. The standard seems to mix up the two completely separate
concepts of initializer (syntax/semantics issue of a language element,
needed to be introduced because of the different between a constructor call
and an assignment operator call) and the act of initialization. These are
separate concepts, and that mistake shows up its ugly head when using PODs
(having no constructors):

int i = 0;

Initializer by the language semantics. Initialization by the act.

int i;

for (i = 0;...

Assignment by the language semantics. Initialization by the act.

This looks like fun, so I'll take my stab at it.

When a variable is made available to a program, the compiler must have
generated code that sets aside some area of memory for use by the program.
If the generated code of the compiler also puts a predetermined value in the
area of memory, this is called initialization. I.e. the memory allocated to
the variable, if examined with (say) a cout << operation, will show a value
that the programmer specified in the declaration that requested the
allocation. However, if the programmer did not specify an initial value in
the declaration, all bets are off. The initial value of the variable could
be anything and is usually whatever was in the memory area prior to its
being used as the variable being declared.

For certain structures, the compiler will zero-initialize members
implicitly, without the programmer having to specifically declare an initial
value. In the case of arrays, for example, if fewer initial values are
provided than the array can store, zero-initialiation will be done for the
remaining array elements.

Once the variable is available to the program, any movement of a different
value into the variable, such as with an assignment operation, is called
assignment.
The entire issue is: What is in the variable immediately after its
"creation?" If it is a determinate value, specified by the programmer, it
has been "initialized" by the compiler.

[Note: by "memory area" I do not exclude use of registers, data bases, or
any other mechanism any given compiler chooses to use for variable storage.]

Does this make sense to anyone?

 

[Gary Labowitz]

Nope. An initialized object of any kind *might* contain an indeterminate
value (like initialized by rand()) but it contains a value which is in the
value set of the type for that object (object in C sense). Uninitialized
(auto) PODs do not fullfill this requirement. If something is not
initialized and it might not even be of its own type is uninitialized.

Disagree. The type of a variable specifies two things: the size of memory to
be accessed and the encoding of the bits in that area. As far as I know,
there are not "invalid" combinations of bits for a type. Whatever is in
there is interpreted according to the encoding of the type. The value this
results in is usually garbage, but is still a value of the type.

Having said that, I wonder if bool types MUST be either all ones or all
zeros. Would a bool containing mixed bits confuse a formatter (like cout) or
would it just say "Hmmm, not all zeros --- therefore, true!"