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

[Gavin Deane]

"Ying Yang" <Yi******@hotma il.com> wrote in message news:<3f******* *@news.iprimus. com.au>...

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

You need to have an item in the initialize list if it's a constant or
a reference data member.
You also need to have the base class constructor in the initializer
list if the base class does not have a default contructor.

If my class does not extend any class then there would be no base class your
referring to. Maybe you mean a default constructor of a class must always be
present when you use an initialisation list. Can you be more clear?

What foo meant was that _if_ your class is derived from another class
_and_ initialising the base class with its default constructor is
inappropriate, then you must use your constructor's initialiser list
to call the appropriate base class constructor. There is no other way.
If your class is not derived from another class, this is obviously not
relevant.

I believe that if your class has an array member, it is not possible
to initialise the array elements in the initialiser list.

GJD

[White Wolf]

tom_usenet wrote:
[SNIP]

An action of giving a determined value to
some object.
Who says?

Common sense? Sanity? Logic? Vulcans?
Not the standard.
Then the standards is making a mistake. It does not matter if the standard
defines doing noting as initialization, it will not make it to be.
struct A
{
int i;
A(int){}
};

A a(1); // initialized? yes.
No. Noone has ever touched it, so no action was taken on it, so it is not
initialized. Unless it a global, which gets initilized to all zeros.
determinate value? no.
Not interesting. it is not initialized. If I initialize it using random,
it will be initialized.

If this is not done, well, then it is not initialized.

Your definition of initialized is wrong.

No. My definition of initilized is right. To initialize something you have
to *do* something. Otherwise you did not initialize it.
e.g. 6.7/2
"Variables with automatic storage duration (3.7.2) are initialized
each time their declaration-0statement is executed."
This is one of the places where the standard has tried to change the human
language, and logic and failed. The are not initialized. Nothing
whatsoever happens to them. Their memory imagine (bit image) might not even
conform to those of the type they are supposed to represent. They are not
initialized.

Try to define a constant integer (automatic) and not give it an initializer.
Will it work? Nope. Why not? Because it is not initialized.
It doesn't say that you initialize them. It says that they are
initialized (maybe by you, maybe by the compiler, maybe by the great
goddess of undefined behaviour).
Not doing anythhing does not count (for me) as an action. But I probably
will collect those who believe that noop count as an action and will built a
successful business on them. I"I have put oil into your car, but you cannot
look at it. Unless you put new oil into your car it is undetermined if
there is oil in your car." :-)

This is a sort of foxymoron. A smart way of telling that if I do not
initialize (give a value) to an object I still initialize (give a
value) to an object.

Why the use of "I"? The compiler can give a value to an object (aka
initialize it). This value might be indeterminate.

We both no it does *not* give any value, just starts to use the address.
Here is an example
of just that (from 8.5.1/8):

"An empty initializer*lis t can be used to initialize any aggregate. If
the aggregate is not an empty class, then each member of the aggregate
shall be initialized with a value of the form T() (5.2.3), where T
represents the type of the uninitialized member. "

Here, "initialize d" means "initialize d by the compiler/runtime",
whereas the "uninitiali zed" means "not directly initialized by an
initializer".

Ahha! So basically they *are not* initialized.

The lvalue to rvalue thing applies to things that have been
initialized too:

int* p = new int;
delete p; //p now indeterminate (but obviously initialized)

Nope. It is invalid, not indetermined.

Ahh, yes, although it might be useful to allow it to fall under 4.1 by
changing the language in both places to "inderminat e value" or
similar.

The standard seems to be a bit sloppy about its use of the word
"initialize " and this could probably do with clearing up...

Yep, I guess so. And just be brave and admit the obvious: non-const PODs
can be initialized during their lifetime *later* than their actual
definition takes place. However that initialization takes the form of an
assignment, not the form of an initializer. It is not too much cleaner, but
it is true.

--
WW aka Attila

[White Wolf]

tom_usenet wrote:

On Mon, 15 Sep 2003 16:51:15 +0300, "White Wolf" <wo***@freemail .hu>
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

Indeed, however this doesn't have to involve an initializer.

Well, initial value is something which corresponds to the requirements of
the type being initialized. An undetermined and unaccessible value just do
not cut it.

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

Nope, the compiler gives an initial value to PODs if you don't bother.
This is also initialization.

No, it does not give to automatic ones. No, sir, no. It just starts to use
the address and any value which happends to be there. It makes no effort,
nil, nada, zip, arj, pak, tar.gz (hm, did I lost the track? ;-) ) to give it
any value, which would be a value right for the given type POD T.

"initialize " and "provide an initializer for" are best thought of as
different things. initialize is something the compiler (or exe) does
to a variable. It does it whether you provide an initializer or not.

Yes. But the compiler (or the exe) does *nothing* to uninitialized
PODs!

Are you saying that the bytes making up the value representation of a
POD have to be changed for initialization to have occurred?

Bingo!
I don't think the standard backs you on this!

The standard is wrong in its wording. It makes absolutely no sense. It
overcomplicates the issue.

--
WW aka Attila

[tom_usenet]

On Mon, 15 Sep 2003 20:04:13 +0300, "White Wolf" <wo***@freemail .hu>
wrote:

An action of giving a determined value to
some object.

Who says?

Common sense? Sanity? Logic? Vulcans?

Not the standard.

Then the standards is making a mistake. It does not matter if the standard
defines doing noting as initialization, it will not make it to be.

The standard is the only place that defines the concept of
initialization in C++! However, I agree its version of the concept
disagrees with that of most other languages (including possibly C,
although I've never studied that standard).

struct A
{
int i;
A(int){}
};

A a(1); // initialized? yes.

No. Noone has ever touched it, so no action was taken on it, so it is not
initialized. Unless it a global, which gets initilized to all zeros.

But it is initialized! With the value 1. A constructor is called. Are
you saying that constructors don't initialize in C++?

If this is not done, well, then it is not initialized.

Your definition of initialized is wrong.

No. My definition of initilized is right. To initialize something you have
to *do* something. Otherwise you did not initialize it.

In the C++ abstract machine, the variable is initialized with an
undeterminable value. I agree that on real implementations this
involves doing nothing.

e.g. 6.7/2
"Variables with automatic storage duration (3.7.2) are initialized
each time their declaration-0statement is executed."

This is one of the places where the standard has tried to change the human
language, and logic and failed. The are not initialized. Nothing
whatsoever happens to them. Their memory imagine (bit image) might not even
conform to those of the type they are supposed to represent. They are not
initialized.

Try to define a constant integer (automatic) and not give it an initializer.
Will it work? Nope. Why not? Because it is not initialized.

That is just a feature to avoid programming errors - what is the point
of a constant with an indeterminate value?

This is a sort of foxymoron. A smart way of telling that if I do not
initialize (give a value) to an object I still initialize (give a
value) to an object.

Why the use of "I"? The compiler can give a value to an object (aka
initialize it). This value might be indeterminate.

We both no it does *not* give any value, just starts to use the address.

It can give it a particular value if it wants - the point is that you
can't legally determine what that value is. e.g. it might give all
ints the bit pattern 0xDEADBEEF or whatever, in a debug build.

Here is an example
of just that (from 8.5.1/8):

"An empty initializer*lis t can be used to initialize any aggregate. If
the aggregate is not an empty class, then each member of the aggregate
shall be initialized with a value of the form T() (5.2.3), where T
represents the type of the uninitialized member. "

Here, "initialize d" means "initialize d by the compiler/runtime",
whereas the "uninitiali zed" means "not directly initialized by an
initializer".

Ahha! So basically they *are not* initialized.

Not explicitly initialized, but they are implicitly initialized.

Variables with static storage duration are implicitly default
initialized. Variables with automatic storage duration are implicitly
initialized to an indeterminate value. :)

The lvalue to rvalue thing applies to things that have been
initialized too:

int* p = new int;
delete p; //p now indeterminate (but obviously initialized)

Nope. It is invalid, not indetermined.

Ahh, yes, although it might be useful to allow it to fall under 4.1 by
changing the language in both places to "inderminat e value" or
similar.

The standard seems to be a bit sloppy about its use of the word
"initialize " and this could probably do with clearing up...

Yep, I guess so. And just be brave and admit the obvious: non-const PODs
can be initialized during their lifetime *later* than their actual
definition takes place. However that initialization takes the form of an
assignment, not the form of an initializer. It is not too much cleaner, but
it is true.

I think they've chosen the path they have to avoid having excessive
special cases. They've largely used initialized to mean "lifetime has
started". e.g.

int* pint = (int*)::operato r new(sizeof *pint);
//*pint is uninitialized
new (pint) int; //actually a no op!
//*pint is initialized, but indeterminate.
*pint = 10;
//*pint is now determinate.

The distinction is used because otherwise objects could be part
initialized even after construction, and this would get confusing!

Anyway, I don't think we're fundamentally in disagreement - I'm just
presenting a language lawyer argument (that I think you agree with),
while you are presenting a practical argument (that I agree with).

Tom

[White Wolf]

tom_usenet wrote:

The standard is the only place that defines the concept of
initialization in C++! However, I agree its version of the concept
disagrees with that of most other languages (including possibly C,
although I've never studied that standard).
Well, as I said: an official mess is just a mess.

struct A
{
int i;
A(int){}
};

A a(1); // initialized? yes.

No. Noone has ever touched it, so no action was taken on it, so it
is not initialized. Unless it a global, which gets initilized to
all zeros.

But it is initialized! With the value 1. A constructor is called. Are
you saying that constructors don't initialize in C++?

Yes, that is what I am saying. If the class has POD members and the
constructor fails to initialize them the class is not fully initialized.
In the C++ abstract machine, the variable is initialized with an
undeterminable value. I agree that on real implementations this
involves doing nothing.
And that should give a hint. :-)
That is just a feature to avoid programming errors - what is the point
of a constant with an indeterminate value?
Random number generation. :-)
It can give it a particular value if it wants - the point is that you
can't legally determine what that value is. e.g. it might give all
ints the bit pattern 0xDEADBEEF or whatever, in a debug build.
Yes. But it is not required to do so. (I love the DEADBEEF! :-) )

"An empty initializer*lis t can be used to initialize any aggregate.
If the aggregate is not an empty class, then each member of the
aggregate shall be initialized with a value of the form T()
(5.2.3), where T represents the type of the uninitialized member. "

Here, "initialize d" means "initialize d by the compiler/runtime",
whereas the "uninitiali zed" means "not directly initialized by an
initializer".

Ahha! So basically they *are not* initialized.

Not explicitly initialized, but they are implicitly initialized.

"where T represents the type of the uninitialized member"

That says *uninitialized*
Variables with static storage duration are implicitly default
initialized. Variables with automatic storage duration are implicitly
initialized to an indeterminate value. :)
This is the long form of "not really initialized to anything but saying that
would put us into trouble because we had to allow initialization by
assignment" ;-)

The standard seems to be a bit sloppy about its use of the word
"initialize " and this could probably do with clearing up...

Yep, I guess so. And just be brave and admit the obvious: non-const
PODs can be initialized during their lifetime *later* than their
actual definition takes place. However that initialization takes
the form of an assignment, not the form of an initializer. It is
not too much cleaner, but it is true.

I think they've chosen the path they have to avoid having excessive
special cases. They've largely used initialized to mean "lifetime has
started". e.g.

int* pint = (int*)::operato r new(sizeof *pint);
//*pint is uninitialized
new (pint) int; //actually a no op!
//*pint is initialized, but indeterminate.
*pint = 10;
//*pint is now determinate.

Ahh. :-)
The distinction is used because otherwise objects could be part
initialized even after construction, and this would get confusing!
Well, in practice they are.
Anyway, I don't think we're fundamentally in disagreement - I'm just
presenting a language lawyer argument (that I think you agree with),
while you are presenting a practical argument (that I agree with).

We can discuss how much we aggree next to some beers at Kona. :-) I have a
good C++ way to find out if it is OK to drink another beer.

--
WW aka Attila

[jeffc]

"tom_usenet " <to********@hot mail.com> wrote in message
news:83******** *************** *********@4ax.c om...

Who says you can't have function calls?

You can only have function calls as part of expressions, not statements.
You can't simply call a function such as initialize() as Gianni suggested
(as you well know.)

I think you completely misunderstood him:

Maybe so.

[Kevin Goodsell]

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
indetermina te 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" . The standard
committee has recognized at least one occurrence of this inconsistency
in the standard itself.

Initialization is the act of giving an object its initial value. If an
object has any value, it must have been initialized. Therefore, an
object with an indeterminate value has been initialized, and giving a
determinate value to an object that previously had an indeterminate
value is not initialization.

From another part of this thread:

initialization - giving an object an initial value. Initialization
differs from assignment in that there is no previous value involved.
Initialization is done by constructors.

http://www.research.att.com/~bs/glossary.html

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

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Alf P. Steinbach]

On Mon, 15 Sep 2003 18:41:39 GMT, Kevin Goodsell <us************ *********@never box.com> 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
indeterminat e 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" . The standard
committee has recognized at least one occurrence of this inconsistency
in the standard itself.

Initializati on is the act of giving an object its initial value. If an
object has any value, it must have been initialized. Therefore, an
object with an indeterminate value has been initialized, and giving a
determinate value to an object that previously had an indeterminate
value is not initialization.

From another part of this thread:

>initializati on - giving an object an initial value. Initialization
differs from assignment in that there is no previous value involved.
Initializati on is done by constructors.

http://www.research.att.com/~bs/glossary.html

Appeal to authority is a very very weak argument.

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...
Also, the standard clearly uses the term "initialization " to describe
something that happens at object creation, not afterward.

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 "constructi on" seems to be reserved for C++ constructor
execution.

Having such terms is necessary in order to discuss initialization. ;-)

[White Wolf]

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.
The standard
committee has recognized at least one occurrence of this inconsistency
in the standard itself.
They take the wrong turn here.
Initialization is the act of giving an object its initial value.
Exactly an act. That act makes the raw memory area to conform to the
requirements of its type.
If an object has any value, it must have been initialized.
False. Any raw memory has some value - from "series of bytes" perspective.
But if a given object of type T has a value, what may not even be in the
accepted value set of that type and furthermore this value just "happens to
be there", it is not the result of an action (note, you also use the word
act) then this object of type T is *not* initialized. Both of the major
attributes of an initialization are missing: there was no act of
initialization and the object may not even conform to its own type.
Therefore, an
object with an indeterminate value has been initialized, and giving a
determinate value to an object that previously had an indeterminate
value is not initialization.
Nope, it has not been initialized. There was no act of initialization.
From another part of this thread:

> initialization - giving an object an initial value. Initialization
differs from assignment in that there is no previous value involved.
Initialization is done by constructors.

http://www.research.att.com/~bs/glossary.html
Then again: authority is not an issue here. Logic and common sense is. My
ears may not be pointy, but I value logic. ;-)
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.

--
WW aka Attila

[White Wolf]

Alf P. Steinbach wrote:
[SNIP]

>> initialization - giving an object an initial value. Initialization
differs from assignment in that there is no previous value involved.
Initialization is done by constructors.

http://www.research.att.com/~bs/glossary.html

Appeal to authority is a very very weak argument.

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

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

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 "constructi on" seems to be reserved for C++ constructor
execution.

Agreed. Some additional toughts:

The job of a constructor is to initialize the raw memory of a given instance
class type T to represent a valid instance of that class type T. It might
be valid for the definition of a class type T to leave one or more of its
POD members uninitialized, as long as it is ensured that they will not be
used as rvalues. If they can be, the results are undefined.

--
WW aka Attila