class object initialisation

[tom_usenet]

Re: class object initialisation

On Mon, 15 Sep 2003 16:51:15 +0300, "White Wolf" <wolof@freemail .hu>
wrote:
[color=blue]
>tom_usenet wrote:
>[SNIP][color=green]
>> 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]
>
>Initializati on == giving an initial value[/color]

Indeed, however this doesn't have to involve an initializer.
[color=blue]
>not giving an initial value (but leave garbage there) != initialization[/color]

Nope, the compiler gives an initial value to PODs if you don't bother.
This is also initialization.
[color=blue]
>[color=green]
>> "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![/color]

Are you saying that the bytes making up the value representation of a
POD have to be changed for initialization to have occurred? I don't
think the standard backs you on this!

Tom

[jeffc]

Re: class object initialisation


"foo" <maisonave@axte r.com> wrote in message
news:c11783b0.0 309131929.a7b14 fe@posting.goog le.com...[color=blue]
> "jeffc" <nobody@nowhere .com> wrote in message[/color]
news:<3f622fa7_ 4@news1.prserv. net>...[color=blue][color=green]
> > "Erik" <no@spam.com> wrote in message news:bjspcn$r22 $1@news.lth.se. ..[color=darkred]
> > > > The basic rule of thumb is that anything that can go in the[/color][/color][/color]
initialize[color=blue][color=green]
> > list[color=darkred]
> > > > should go there. Obviously, you can't put something like this in[/color][/color][/color]
there:[color=blue][color=green][color=darkred]
> > > > 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]
> >
> > Yeah, maybe simple "if" cases like that, but you can't put logic or[/color][/color]
function[color=blue][color=green]
> > calls (other than base class constructors) in the initializer list. You
> > added an expression, not a statement.[/color]
> There are plenty of things you can put in the initializer list.
> You can put functions, additions, conditon logic, and more.[/color]

And there are plenty of things you can't. You can put expressions in there,
but you can't put statements in there. You can't call functions (alone),
you can't use for or while loops, you can't... well, you already know what
you can't do.

[jeffc]

Re: class object initialisation


"Ron Natalie" <ron@sensor.com > wrote in message
news:3f622fa9$0 $51871$9a6e19ea @news.newshosti ng.com...[color=blue]
>
> "jeffc" <nobody@nowhere .com> wrote in message[/color]
news:3f622ea6_1 @news1.prserv.n et...[color=blue][color=green]
> >[/color]
>[color=green][color=darkred]
> > > 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[/color][/color]
initializer[color=blue][color=green]
> > list?[/color]
>
> Same way you call any other function.[/color]

Yeah, right.

[jeffc]

Re: class object initialisation


"Ron Natalie" <ron@sensor.com > wrote in message
news:3f62303f$0 $51808$9a6e19ea @news.newshosti ng.com...[color=blue]
>
> "jeffc" <nobody@nowhere .com> wrote in message[/color]
news:3f622fa7_4 @news1.prserv.n et...[color=blue]
>[color=green][color=darkred]
> > > Many, if not most, of those cases can be covered by the ?: operator:
> > > MyClass(int a) : i(a ? 2 : 4) {}[/color]
> >
> > Yeah, maybe simple "if" cases like that, but you can't put logic or[/color][/color]
function[color=blue][color=green]
> > calls (other than base class constructors) in the initializer list. You
> > added an expression, not a statement.[/color]
>
> Who says you can't have function calls?[/color]

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

[tom_usenet]

Re: class object initialisation

On Mon, 15 Sep 2003 11:29:54 -0400, "jeffc" <nobody@nowhere .com>
wrote:
[color=blue]
>
>"Ron Natalie" <ron@sensor.com > wrote in message
>news:3f62303f$ 0$51808$9a6e19e a@news.newshost ing.com...[color=green]
>>
>> "jeffc" <nobody@nowhere .com> wrote in message[/color]
>news:3f622fa7_ 4@news1.prserv. net...[color=green]
>>[color=darkred]
>> > > Many, if not most, of those cases can be covered by the ?: operator:
>> > > MyClass(int a) : i(a ? 2 : 4) {}
>> >
>> > Yeah, maybe simple "if" cases like that, but you can't put logic or[/color][/color]
>function[color=green][color=darkred]
>> > calls (other than base class constructors) in the initializer list. You
>> > added an expression, not a statement.[/color]
>>
>> Who says you can't have function calls?[/color]
>
>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.)[/color]

I think you completely misunderstood him:

struct A
{
int a;
static int doCalc(int val);
A(int val): a(doCalc(val))
{
}
};

That was exactly the kind of thing that Gianni was suggesting - if you
can't put the logic inline, make a function for it. If your member is
const or a reference, you have no choice but to do so.

Tom

[Gavin Deane]

Re: class object initialisation

"Ying Yang" <YingYang@hotma il.com> wrote in message news:<3f65764e_ 1@news.iprimus. com.au>...[color=blue][color=green][color=darkred]
> > > Hi,
> > >
> > > I have always been taught to use an inialization list for initialising[/color][/color]
> data[color=green][color=darkred]
> > > members of a class. I realize that initialsizing primitives and pointers[/color][/color]
> use[color=green][color=darkred]
> > > 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[/color][/color]
> data[color=green][color=darkred]
> > > members of a class?
> > >
> > >
> > > Regards
> > > Adi[/color]
> >
> >
> > 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.[/color]
>
> 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]

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]

Re: class object initialisation

tom_usenet wrote:
[SNIP][color=blue][color=green]
>> An action of giving a determined value to
>> some object.[/color]
>
> Who says?[/color]

Common sense? Sanity? Logic? Vulcans?
[color=blue]
> Not the standard.[/color]

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.
[color=blue]
> struct A
> {
> int i;
> A(int){}
> };
>
> A a(1); // initialized? yes.[/color]

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.
[color=blue]
> determinate value? no.[/color]

Not interesting. it is not initialized. If I initialize it using random,
it will be initialized.
[color=blue][color=green]
>> If this is not done, well, then it is not initialized.[/color]
>
> Your definition of initialized is wrong.[/color]

No. My definition of initilized is right. To initialize something you have
to *do* something. Otherwise you did not initialize it.
[color=blue]
> e.g. 6.7/2
> "Variables with automatic storage duration (3.7.2) are initialized
> each time their declaration-0statement is executed."[/color]

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

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

We both no it does *not* give any value, just starts to use the address.
[color=blue]
> 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]

Ahha! So basically they *are not* initialized.
[color=blue][color=green][color=darkred]
>>> 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...[/color]

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]

Re: class object initialisation

tom_usenet wrote:[color=blue]
> On Mon, 15 Sep 2003 16:51:15 +0300, "White Wolf" <wolof@freemail .hu>
> wrote:
>[color=green]
>> tom_usenet wrote:
>> [SNIP][color=darkred]
>>> 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[/color]
>
> Indeed, however this doesn't have to involve an initializer.[/color]

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.
[color=blue][color=green]
>> not giving an initial value (but leave garbage there) !=
>> initialization[/color]
>
> Nope, the compiler gives an initial value to PODs if you don't bother.
> This is also initialization.[/color]

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.
[color=blue][color=green][color=darkred]
>>> "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![/color]
>
> Are you saying that the bytes making up the value representation of a
> POD have to be changed for initialization to have occurred?[/color]

Bingo!
[color=blue]
> I don't think the standard backs you on this![/color]

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

--
WW aka Attila

[tom_usenet]

Re: class object initialisation

On Mon, 15 Sep 2003 20:04:13 +0300, "White Wolf" <wolof@freemail .hu>
wrote:
[color=blue][color=green][color=darkred]
>>> An action of giving a determined value to
>>> some object.[/color]
>>
>> Who says?[/color]
>
>Common sense? Sanity? Logic? Vulcans?
>[color=green]
>> Not the standard.[/color]
>
>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.[/color]

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).
[color=blue][color=green]
>> struct A
>> {
>> int i;
>> A(int){}
>> };
>>
>> A a(1); // initialized? yes.[/color]
>
>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.[/color]

But it is initialized! With the value 1. A constructor is called. Are
you saying that constructors don't initialize in C++?
[color=blue][color=green][color=darkred]
>>> If this is not done, well, then it is not initialized.[/color]
>>
>> Your definition of initialized is wrong.[/color]
>
>No. My definition of initilized is right. To initialize something you have
>to *do* something. Otherwise you did not initialize it.[/color]

In the C++ abstract machine, the variable is initialized with an
undeterminable value. I agree that on real implementations this
involves doing nothing.
[color=blue][color=green]
>> e.g. 6.7/2
>> "Variables with automatic storage duration (3.7.2) are initialized
>> each time their declaration-0statement is executed."[/color]
>
>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.[/color]

That is just a feature to avoid programming errors - what is the point
of a constant with an indeterminate value?
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>
>We both no it does *not* give any value, just starts to use the address.[/color]

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.
[color=blue][color=green]
>> 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]
>
>Ahha! So basically they *are not* initialized.[/color]

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

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]

Re: class object initialisation

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

Well, as I said: an official mess is just a mess.
[color=blue][color=green][color=darkred]
>>> struct A
>>> {
>>> int i;
>>> A(int){}
>>> };
>>>
>>> A a(1); // initialized? yes.[/color]
>>
>> 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.[/color]
>
> But it is initialized! With the value 1. A constructor is called. Are
> you saying that constructors don't initialize in C++?[/color]

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.
[color=blue]
> In the C++ abstract machine, the variable is initialized with an
> undeterminable value. I agree that on real implementations this
> involves doing nothing.[/color]

And that should give a hint. :-)
[color=blue]
> That is just a feature to avoid programming errors - what is the point
> of a constant with an indeterminate value?[/color]

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

Yes. But it is not required to do so. (I love the DEADBEEF! :-) )
[color=blue][color=green][color=darkred]
>>> "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]
>>
>> Ahha! So basically they *are not* initialized.[/color]
>
> Not explicitly initialized, but they are implicitly initialized.[/color]

"where T represents the type of the uninitialized member"

That says *uninitialized*
[color=blue]
> Variables with static storage duration are implicitly default
> initialized. Variables with automatic storage duration are implicitly
> initialized to an indeterminate value. :)[/color]

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" ;-)
[color=blue][color=green][color=darkred]
>>> The standard seems to be a bit sloppy about its use of the word
>>> "initialize " and this could probably do with clearing up...[/color]
>>
>> 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.[/color]
>
> 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.[/color]

Ahh. :-)
[color=blue]
> The distinction is used because otherwise objects could be part
> initialized even after construction, and this would get confusing![/color]

Well, in practice they are.
[color=blue]
> 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).[/color]

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]

Re: class object initialisation


"tom_usenet " <tom_usenet@hot mail.com> wrote in message
news:83nbmvsbnm 9n3a93ve6urh8t1 l2nb7eq7i@4ax.c om...[color=blue][color=green][color=darkred]
> >>
> >> Who says you can't have function calls?[/color]
> >
> >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.)[/color]
>
> I think you completely misunderstood him:[/color]

Maybe so.

[Kevin Goodsell]

Re: class object initialisation

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

Re: class object initialisation

On Mon, 15 Sep 2003 18:41:39 GMT, Kevin Goodsell <usenet1.spamfr ee.fusion@never box.com> wrote:
[color=blue]
>White Wolf wrote:[color=green]
>> tom_usenet wrote:
>> [SNIP]
>>[color=darkred]
>>>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."[/color]
>>
>>
>> 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" . 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[/color]

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


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

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

[White Wolf]

Re: class object initialisation

Kevin Goodsell wrote:[color=blue]
> White Wolf wrote:[color=green]
>> tom_usenet wrote:
>> [SNIP]
>>[color=darkred]
>>> 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]
>
> 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=blue]
> The standard
> committee has recognized at least one occurrence of this inconsistency
> in the standard itself.[/color]

They take the wrong turn here.
[color=blue]
> Initialization is the act of giving an object its initial value.[/color]

Exactly an act. That act makes the raw memory area to conform to the
requirements of its type.
[color=blue]
> If an object has any value, it must have been initialized.[/color]

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

Nope, it has not been initialized. There was no act of initialization.
[color=blue]
> 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[/color]

Then again: authority is not an issue here. Logic and common sense is. My
ears may not be pointy, but I value logic. ;-)
[color=blue]
> 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
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]

Re: class object initialisation

Alf P. Steinbach wrote:
[SNIP][color=blue][color=green]
>>

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

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