class object initialisation

[A]

Hi,

I have always been taught to use an inialization list for initialising data
members of a class. I realize that initialsizing primitives and pointers use
an inialization list is exactly the same as an assignment, but for class
types it has a different effect - it calls the copy constructor.

My question is when to not use an initalisation list for initialising data
members of a class?
Regards
Adi

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.516 / Virus Database: 313 - Release Date: 1/09/2003

[Kevin Goodsell]

White Wolf wrote:

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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[tom_usenet]

On Mon, 15 Sep 2003 22:47:37 GMT, al***@start.no (Alf P. Steinbach)
wrote:

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

[Alf P. Steinbach]

On Tue, 16 Sep 2003 09:54:49 +0100, tom_usenet <to********@hot mail.com> wrote:

On Mon, 15 Sep 2003 22:47:37 GMT, al***@start.no (Alf P. Steinbach)
wrote:

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,

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.

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

--
Attila aka WW

[tom_usenet]

On Mon, 15 Sep 2003 23:14:18 +0300, "White Wolf" <wo***@freemail .hu>
wrote:

Kevin Goodsell wrote:

White Wolf wrote:

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.

Also, the standard clearly uses the term "initialization " to describe
something that happens at object creation, not afterward.

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
uninitialize d 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
"uninitiali zed" but must use "indetermin ate" or perhaps "singular". Is
it really useful to talk about uninitialized PODs then, rather than
ones with indeterminate values?

Tom

[Attila Feher]

tom_usenet wrote:

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.

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.

Also, the standard clearly uses the term "initialization " to
describe something that happens at object creation, not afterward.

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

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
"uninitiali zed" but must use "indetermin ate" 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. "Indetermin ate 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.

--
Attila aka WW

[Alexander Terekhov]

Attila Feher wrote:
[...]

Indeterminate is ...

"either an unspecified value or a trap representation"

"unspecifie d 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. :-)

--
Attila aka WW

[Gary Labowitz]

"Attila Feher" <at**********@l mf.ericsson.se> wrote in message
news:bk******** **@newstree.wis e.edt.ericsson. se...

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 "initialize d" 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]

"White Wolf" <wo***@freemail .hu> wrote in message
news:bk******** **@phys-news1.kolumbus. fi...

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!"
--
Gary