class object initialisation

**Kevin Goodsell** · Jul 19 '05, 05:34 PM

Re: class object initialisation

White Wolf wrote:[color=blue]
>
>
> 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[/color]

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.
[color=blue]
> (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.[/color]

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).
[color=blue]
> The initialization (giving a correct initial value
> and thereby forming a valid POD type T) can be done using an assigment.
>[/color]

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** · Jul 19 '05, 05:35 PM

Re: class object initialisation

Alf P. Steinbach wrote:[color=blue]
>
> Appeal to authority is a very very weak argument.[/color]

So we can't appeal to the standard and the people who wrote it when
discussing the language they defined?
[color=blue]
>
> 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...[/color]

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

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** · Jul 19 '05, 05:35 PM

Re: class object initialisation

On Mon, 15 Sep 2003 21:23:16 GMT, Kevin Goodsell <usenet1.spamfr ee.fusion@never box.com> wrote:
[color=blue]
>Alf P. Steinbach wrote:[color=green]
>>
>> Appeal to authority is a very very weak argument.[/color]
>
>So we can't appeal to the standard and the people who wrote it when
>discussing the language they defined?[/color]

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.

[color=blue]
>...
>The common usage is technically incorrect, but rarely harmful.[/color]

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

**Kevin Goodsell** · Jul 19 '05, 05:35 PM

Re: class object initialisation

Alf P. Steinbach wrote:
[color=blue]
> On Mon, 15 Sep 2003 21:23:16 GMT, Kevin Goodsell <usenet1.spamfr ee.fusion@never box.com> wrote:
>[color=green]
>>So we can't appeal to the standard and the people who wrote it when
>>discussing the language they defined?[/color]
>
>
> Those two questions concern a very different matter than redefining
> a common term.[/color]

I never suggested that.
[color=blue]
>
> The answer to the first is yes, you can.
>
> The answer to the second is yes, you can, but of limited value.[/color]

(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** · Jul 19 '05, 05:35 PM

Re: class object initialisation

On Mon, 15 Sep 2003 21:55:09 GMT, Kevin Goodsell <usenet1.spamfr ee.fusion@never box.com> wrote:
[color=blue]
>Alf P. Steinbach wrote:
>[color=green]
>> On Mon, 15 Sep 2003 21:23:16 GMT, Kevin Goodsell <usenet1.spamfr ee.fusion@never box.com> wrote:
>>[color=darkred]
>>>So we can't appeal to the standard and the people who wrote it when
>>>discussing the language they defined?[/color]
>>
>>
>> Those two questions concern a very different matter than redefining
>> a common term.[/color]
>
>I never suggested that.[/color]

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.

[color=blue][color=green]
>> The answer to the first is yes, you can.
>>
>> The answer to the second is yes, you can, but of limited value.[/color]
>
>(If I understand you correctly...)
>
>The people that wrote the standard are the only ones who can properly
>describe the intent in some cases.[/color]

Is that the case here?

**Kevin Goodsell** · Jul 19 '05, 05:35 PM

Re: class object initialisation

Alf P. Steinbach wrote:
[color=blue]
>
> 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.[/color]

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.
[color=blue][color=green]
>>
>>The people that wrote the standard are the only ones who can properly
>>describe the intent in some cases.[/color]
>
> Is that the case here?
>[/color]

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** · Jul 19 '05, 05:35 PM

Re: class object initialisation

On Mon, 15 Sep 2003 22:17:00 GMT, Kevin Goodsell <usenet1.spamfr ee.fusion@never box.com> wrote:
[color=blue]
>Alf P. Steinbach wrote:
>[color=green]
>>
>> 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.[/color]
>
>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.[/color]

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.

[color=blue][color=green][color=darkred]
>>>The people that wrote the standard are the only ones who can properly
>>>describe the intent in some cases.[/color]
>>
>> Is that the case here?
>>[/color]
>
>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[/color]

See above.

[color=blue]
>(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).[/color]

**White Wolf** · Jul 19 '05, 05:35 PM

Re: class object initialisation

Kevin Goodsell wrote:[color=blue]
> Alf P. Steinbach wrote:[color=green]
>>
>> Appeal to authority is a very very weak argument.[/color]
>
> So we can't appeal to the standard and the people who wrote it when
> discussing the language they defined?[/color]

You have appealed to Bjarne, not to the standard.
[color=blue][color=green]
>> 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...[/color]
>
> 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.[/color]

And it is still wrong.
[color=blue]
> 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.[/color]

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** · Jul 19 '05, 05:36 PM

Re: class object initialisation

Kevin Goodsell wrote:
[SNIP][color=blue]
> The people that wrote the standard are the only ones who can properly
> describe the intent in some cases.[/color]

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** · Jul 19 '05, 05:36 PM

Re: class object initialisation

Kevin Goodsell wrote:[color=blue]
> White Wolf wrote:[color=green]
>>
>>
>> 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[/color]
>
> 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.[/color]

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".
[color=blue]
> 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.[/color]

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.
[color=blue]
> Assignment can, and then the object is considered,
> for all intents and purposes, initialized, and usable as an rvalue.[/color]

In other words: initialized.
[color=blue]
> The only part of this debate that is important at all is the fact that
> initialization and assignment are different, and mutually exclusive.[/color]

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;
[color=blue]
> But it's not initialization in the sense that the standard uses it.[/color]

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. ;-))
[color=blue]
> 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).[/color]

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.
[color=blue][color=green]
>> The initialization (giving a correct initial value
>> and thereby forming a valid POD type T) can be done using an
>> assigment.[/color]
>
> I don't know why we are still debating this when the standard is so
> clear on it.[/color]

Because something wrong clearly said is still wrong. And I care about logic
and not about authority.
[color=blue]
> Show me anywhere in the standard where it is even
> suggested that assignment can constitute initialization.[/color]

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

**Kevin Goodsell** · Jul 19 '05, 05:36 PM

Re: class object initialisation

White Wolf wrote:
[color=blue]
> Kevin Goodsell wrote:
> [SNIP]
>[color=green]
>>The people that wrote the standard are the only ones who can properly
>>describe the intent in some cases.[/color]
>
>
> Then the wording of the standard (in those cases) is weak. I mean C++ is
> complicated enough without making its standard hard to understand.
>[/color]

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** · Jul 19 '05, 05:36 PM

Re: class object initialisation

On Mon, 15 Sep 2003 22:47:37 GMT, alfps@start.no (Alf P. Steinbach)
wrote:
[color=blue]
>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>[/color]

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** · Jul 19 '05, 05:36 PM

Re: class object initialisation

On Tue, 16 Sep 2003 09:54:49 +0100, tom_usenet <tom_usenet@hot mail.com> wrote:
[color=blue]
>On Mon, 15 Sep 2003 22:47:37 GMT, alfps@start.no (Alf P. Steinbach)
>wrote:
>[color=green]
>>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>[/color]
>
>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,[/color]

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.

[color=blue]
>since not everyone was aware of this new special C++ meaning.[/color]

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.

[color=blue]
>There are several other places where this "mistake" has been made with
>initialize.[/color]

You don't say... ;-)

[color=blue]
>Still, I think the intent of the standard is clear in all the places
>discussed[/color]

It is.

[color=blue]
>whichever meaning of initialized it is using at that place,
>so it isn't a major problem.[/color]

Right.

**Attila Feher** · Jul 19 '05, 05:36 PM

Re: class object initialisation

tom_usenet wrote:
[SNIP][color=blue]
> 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.[/color]

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** · Jul 19 '05, 05:36 PM

Re: class object initialisation

On Mon, 15 Sep 2003 23:14:18 +0300, "White Wolf" <wolof@freemail .hu>
wrote:
[color=blue]
>Kevin Goodsell wrote:[color=green]
>> White Wolf wrote:[color=darkred]
>>> 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[/color]
>>
>> 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" .[/color]
>
>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.[/color]

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

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

class object initialisation

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment