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:

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 "uninitiali zed" (which actually means "indetermin ate" 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
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

Alf P. Steinbach wrote:

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.

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.

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
--
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 21:23:16 GMT, Kevin Goodsell <us************ *********@never box.com> wrote:

Alf P. Steinbach wrote:

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?

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]

Alf P. Steinbach wrote:

On Mon, 15 Sep 2003 21:23:16 GMT, Kevin Goodsell <us************ *********@never box.com> wrote:

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.

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
--
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 21:55:09 GMT, Kevin Goodsell <us************ *********@never box.com> wrote:

Alf P. Steinbach wrote:

On Mon, 15 Sep 2003 21:23:16 GMT, Kevin Goodsell <us************ *********@never box.com> wrote:

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.

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.

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.

Is that the case here?

[Kevin Goodsell]

Alf P. Steinbach wrote:

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 "uninitiali zed" (or "indeterminate" )
status from the object. But in the C++ standard terminology,
"initialization " is considered to be what is done by, e.g., constructors.

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

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
--
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 22:17:00 GMT, Kevin Goodsell <us************ *********@never box.com> wrote:

Alf P. Steinbach wrote:

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 "uninitiali zed" (or "indeterminate" )
status from the object. But in the C++ standard terminology,
"initializatio n" 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.

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

Is that the case here?

Could be. If there were an explicit definition for any of the terms
"initializatio n", "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.

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

[White Wolf]

Kevin Goodsell wrote:

Alf P. Steinbach wrote:

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?

You have appealed to Bjarne, not to the standard.

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.

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

--
WW aka Attila

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

--
WW aka Attila

[White Wolf]

Kevin Goodsell wrote:

White Wolf wrote:

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.

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 "initializa tion 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 "uninitiali zed" (which actually means "indetermin ate" 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.

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.

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.

--
WW aka Attila