class object initialisation

[tom_usenet]

Re: class object initialisation

On Mon, 15 Sep 2003 14:14:13 +0300, "Attila Feher"
<attila.feher@l mf.ericsson.se> wrote:
[color=blue]
>Karl Heinz Buchegger wrote:[color=green]
>> Ying Yang wrote:[color=darkred]
>>>
>>>
>>> int i; //declared but not initialised[/color]
>>
>> wrong. initialized to an undetermined value. Initialization.[/color]
>
>
>Wrong. This i, if it has an automatic storage, is not initialized.
>Accessing it for anything else then writing (assigment or initialization) it
>(well, reading it in any way) is undefined behavior.[/color]

The lvalue to rvalue conversion is undefined for indeterminate values
(use of the term "initialize d" has been recognized as a defect in the
standard).

According to other parts of the standard (see my other posts), the
above does count as initialization to an indeterminate value.

Tom

[Gary Labowitz]

Re: class object initialisation

"Karl Heinz Buchegger" <kbuchegg@gasca d.at> wrote in message
news:3F65AC45.3 F1CD53D@gascad. at...[color=blue]
>
>
> Attila Feher wrote:[color=green]
> >
> > Karl Heinz Buchegger wrote:[color=darkred]
> > > Ying Yang wrote:
> > >>
> > >>
> > >> int i; //declared but not initialised
> > >
> > > wrong. initialized to an undetermined value. Initialization.[/color]
> >
> > Wrong.[/color]
>
> OK.
> (it was just a wild guess, apologies for that).
>
> This i, if it has an automatic storage, is not initialized.[color=green]
> > Accessing it for anything else then writing (assigment or[/color][/color]
initialization)[color=blue]
>
> If it has not been initialized, how can it be initialized later?
> I thought that initialization can only occour when a variable
> is created. Afterwards it is always assignment.[/color]

Would this allow for assigning a value to a const variable during
construction of the object containing the variable? (Or does it have to be
initialized in the declaration statement?)
Assigning the initial value of a variable (even const, called "final") is
allow in (for example) Java. They appear to keep track of a variable's state
as "uninitiali zed" and define the assigning of a value during construction
as initialization. Does C++ do this? If it did, then calling a constructor
as part of an initialization list is perfectly valid; and I think it is!
--
Gary

[tom_usenet]

Re: class object initialisation

On Fri, 12 Sep 2003 16:34:29 -0400, "jeffc" <nobody@nowhere .com>
wrote:
[color=blue]
>
>"Gianni Mariani" <gi2nospam@mari ani.ws> wrote in message
>news:bjsqne$oo u@dispatch.conc entric.net...[color=green]
>> Erik wrote:
>> ...[color=darkred]
>> >>should go there. Obviously, you can't put something like this in there:
>> >>if (a)
>> >> i = 2;
>> >>else
>> >> i = 4;
>> >
>> >
>> > Many, if not most, of those cases can be covered by the ?: operator:
>> > MyClass(int a) : i(a ? 2 : 4) {}
>> >[/color]
>>
>> Yep - and sometimes it makes sense to create a function that does more
>> complex things so that everything is in the initializer list.[/color]
>
>And how exactly do you propose calling such a function from the initializer
>list?[/color]

How do you think?

MyClass(int a): i(someFunction( a))
{
}

someFunction might be a member (static or otherwise), or a namespace
scope function.

Tom

[Attila Feher]

Re: class object initialisation

tom_usenet wrote:[color=blue]
> specified for an object, the object and its subobjects, if any, have
> an indeterminate initial value;"
>
> In other words, if you don't explicitly initialize an int (which is a
> POD type), it is initialized with an indeterminate initial value.[/color]

No "in other words". They will have an "indetermin ate initial value". They
are *not* initialized. Furthermore (let's not force me to look up the
paragraph) accessing such an uninitialized variable is undefined behavior.
(BTW it is in 4.1 paragraph 1)

--
Attila aka WW

[Attila Feher]

Re: class object initialisation

tom_usenet wrote:[color=blue]
> On Mon, 15 Sep 2003 14:14:13 +0300, "Attila Feher"
> <attila.feher@l mf.ericsson.se> wrote:
>[color=green]
>> Karl Heinz Buchegger wrote:[color=darkred]
>>> Ying Yang wrote:
>>>>
>>>>
>>>> int i; //declared but not initialised
>>>
>>> wrong. initialized to an undetermined value. Initialization.[/color]
>>
>>
>> Wrong. This i, if it has an automatic storage, is not initialized.
>> Accessing it for anything else then writing (assigment or
>> initialization) it (well, reading it in any way) is undefined
>> behavior.[/color]
>
> The lvalue to rvalue conversion is undefined for indeterminate values
> (use of the term "initialize d" has been recognized as a defect in the
> standard).
>
> According to other parts of the standard (see my other posts), the
> above does count as initialization to an indeterminate value.[/color]

If that is what the standard is being changed to, then it is pretty silly.
Initialization is an _action_ being taken. So we say (for automatic/member
PODs): if they are are not initialized then we call this initialization
which never happened as initialization to an indetermined value. Great. It
goes to the deepness of the quantum physics. Furthermore: it has a value,
but that value cannot be read... That suggests me that it is *not*
initialized. It has an indetermined, and non-determinable value. Like the
female-mind vs. male-mind. ;-)

--
Attila aka WW

[Agent Mulder]

Re: class object initialisation

<Shane Beasley>[color=blue]
>it doesn't matter what your opinion (or mine) is; neither of us will
>learn anything about C++ that we didn't already know before this
>thread[/color]
</>

I do learn from this thread. There are always people lurking. And,
for once, it's on topic!
[color=blue]
> "Arguing on the Internet is like competing in the Special Olympics...
> Even if you win, you're still retarded."[/color]

:-)

-X

[tom_usenet]

Re: class object initialisation

On Mon, 15 Sep 2003 15:29:36 +0300, "Attila Feher"
<attila.feher@l mf.ericsson.se> wrote:
[color=blue]
>tom_usenet wrote:[color=green]
>> specified for an object, the object and its subobjects, if any, have
>> an indeterminate initial value;"
>>
>> In other words, if you don't explicitly initialize an int (which is a
>> POD type), it is initialized with an indeterminate initial value.[/color]
>
>No "in other words". They will have an "indetermin ate initial value". They
>are *not* initialized. Furthermore (let's not force me to look up the
>paragraph) accessing such an uninitialized variable is undefined behavior.
>(BTW it is in 4.1 paragraph 1)[/color]

You snipped these words from my post (reproduced in paraphase):

"When no initializer is specified for an object of class type the
object is initialized as specified in 8.5."

Yes, when you don't give an initializer, it is still initialized.
"Initialize r" and "Initialization " are different things. Even if you
don't use an initializer, initialization still takes place.

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)
int* q = p; //error, lvalue-to-rvalue conversion

Tom

[tom_usenet]

Re: class object initialisation

On Mon, 15 Sep 2003 15:35:09 +0300, "Attila Feher"
<attila.feher@l mf.ericsson.se> wrote:
[color=blue]
>If that is what the standard is being changed to, then it is pretty silly.
>Initializati on is an _action_ being taken. So we say (for automatic/member
>PODs): if they are are not initialized then we call this initialization
>which never happened as initialization to an indetermined value. Great. It
>goes to the deepness of the quantum physics. Furthermore: it has a value,
>but that value cannot be read... That suggests me that it is *not*
>initialized. It has an indetermined, and non-determinable value. Like the
>female-mind vs. male-mind. ;-)[/color]

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

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

Tom

[Agent Mulder]

Re: class object initialisation

<tom_usenet>[color=blue]
> If you choose your words carefully it makes more sense[/color]

I am not very into this business of initialization (hard to type)
and assignment, so I try to understand it in a metaphore. The
magician with the White rabbit in the hat. First, there is no hat.
It is flat, doesn't need space. Then, the magician pops up the
hat. It takes up space and provides space. But it is 'empty'.
Is it? Is there a rabbit in the hat?

1. Yes, the rabbit was nicely folded flat in the hat.
2. No, the magician is about to put the rabbit in the hat.

For assignment, putting another rabbit in the hat, we must
visualize a flapdoor at the top of the hat. Is a rabbit POD or
is that not the question?

-X

[Agent Mulder]

Re: class object initialisation

Excuse me, I must add a third possibility (and a fourth)


I am not very into this business of initialization (hard to type)
and assignment, so I try to understand it in a metaphore. The
magician with the White Rabbit in the hat. First, there is no hat.
It is flat, doesn't need space. Then, the magician pops up the
hat. It takes up space and provides space. But it is 'empty'.
Is it? Is there a rabbit in the hat?

1. Yes, the rabbit was nicely folded flat in the hat.
2. No, the magician is about to put the rabbit in the hat.
3.. No, but the rabbit will jump in by itself
4. The Lovely Lady will put the rabbit in the hat

For assignment, putting another rabbit in the hat, we must
visualize a flapdoor at the top of the hat. Is a rabbit POD or
is that not the question?

-X

[color=blue]
>
>[/color]

[White Wolf]

Re: class object initialisation

tom_usenet wrote:
[SNIP][color=blue]
> Yes, when you don't give an initializer, it is still initialized.
> "Initialize r" and "Initialization " are different things. Even if you
> don't use an initializer, initialization still takes place.[/color]

Initialization is the action. An action of giving a determined value to
some object. If this is not done, well, then it is not initialized.

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. Something is not right here. Later of course we say: well, we
have initialized the value but..., hm, khm, we still cannot use it until we
give a value to it. Something is not right. We have to be brave enough to
say: no initialization happens. The POD is not necessarily itself. That
int might not be int! How could we say: it is initialized? If the standard
says that - it is wrong. We can vote to say the Earth is flat and the fixed
center of the universe it will still not be. :-)
[color=blue]
> 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)[/color]

Nope. It is invalid, not indetermined.
[color=blue]
> int* q = p; //error, lvalue-to-rvalue conversion[/color]

Totally different case.

And it is still moving... ;-)

--
WW aka Attila

[White Wolf]

Re: class object initialisation

Gary Labowitz wrote:
[SNIP][color=blue][color=green]
>> This i, if it has an automatic storage, is not initialized.[color=darkred]
>>> Accessing it for anything else then writing (assigment or
>>> initialization)[/color]
>>
>> If it has not been initialized, how can it be initialized later?
>> I thought that initialization can only occour when a variable
>> is created. Afterwards it is always assignment.[/color]
>
> Would this allow for assigning a value to a const variable during
> construction of the object containing the variable?[/color]

Nope. My wording was not clear.
[color=blue]
> (Or does it have
> to be initialized in the declaration statement?)[/color]

It has to be initialized in an initializer list in the a class, or in case
of a static member in its definition (or inside the class if it is an
integral constant). "Normal" constant variables has to be initialized at
their definition.
[color=blue]
> Assigning the initial value of a variable (even const, called
> "final") is allow in (for example) Java.[/color]

OK. In C++ it is called initialization. A const value can only be
initialized and must be initialized. You cannot assign a new value to it
(whatever value means for it).
[color=blue]
> They appear to keep track of
> a variable's state as "uninitiali zed" and define the assigning of a
> value during construction as initialization. Does C++ do this?[/color]

Nope. The closest thing to this in C++ is the way static variables in a
function scope are initialized. But those are the exception, C++ does nto
keep track of initialized state - in the name of the "cause of all evil",
optimization. :-)
[color=blue]
> If it
> did, then calling a constructor as part of an initialization list is
> perfectly valid; and I think it is![/color]

Caling a constructor on the _member_ intiializer list is valid. But not for
the reasons you mention.

--
WW aka Attila

[White Wolf]

Re: class object initialisation

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

Initialization == giving an initial value

not giving an initial value (but leave garbage there) != initialization
[color=blue]
> "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.[/color]

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

--
WW aka Attila

[Ron Natalie]

Re: class object initialisation


"Ying Yang" <YingYang@hotma il.com> wrote in message news:3f65764e_1 @news.iprimus.c om.au...
[color=blue]
> 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?[/color]

Some constructor has to be defined to use an initializer list (doesn't necessarily
have to be the default). This only makes sense simce the initialization list is
part of the constructor definition syntax.

He said IF you have a base class with no default constructor. If you derive from
the derived constructors need to provide initializers so that a valid constructor can
be invoked.

[tom_usenet]

Re: class object initialisation

On Mon, 15 Sep 2003 16:43:58 +0300, "White Wolf" <wolof@freemail .hu>
wrote:
[color=blue]
>tom_usenet wrote:
>[SNIP][color=green]
>> Yes, when you don't give an initializer, it is still initialized.
>> "Initialize r" and "Initialization " are different things. Even if you
>> don't use an initializer, initialization still takes place.[/color]
>
>Initializati on is the action.[/color]

Ok
[color=blue]
> An action of giving a determined value to
>some object.[/color]

Who says? Not the standard.

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

A a(1); // initialized? yes. determinate value? no.
[color=blue]
> If this is not done, well, then it is not initialized.[/color]

Your definition of initialized is wrong. e.g. 6.7/2
"Variables with automatic storage duration (3.7.2) are initialized
each time their declarationsta tement is executed."

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

Why the use of "I"? The compiler can give a value to an object (aka
initialize it). This value might be indeterminate. Here is an example
of just that (from 8.5.1/8):

"An empty initializerlis 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".
[color=blue][color=green]
>> 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)[/color]
>
>Nope. It is invalid, not indetermined.[/color]

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

Tom