class object initialisation

[White Wolf]

tom_usenet wrote:
[SNIP]

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

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.

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.

int* q = p; //error, lvalue-to-rvalue conversion

Totally different case.

And it is still moving... ;-)

 

[White Wolf]

Gary Labowitz wrote:
[SNIP]

Would this allow for assigning a value to a const variable during
construction of the object containing the variable?

Nope. My wording was not clear.

(Or does it have
to be initialized in the declaration statement?)

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.

Assigning the initial value of a variable (even const, called
"final") is allow in (for example) Java.

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

They appear to keep track of
a variable's state as "uninitialized" and define the assigning of a
value during construction as initialization. Does C++ do this?

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.

If it
did, then calling a constructor as part of an initialization list is
perfectly valid; and I think it is!

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

 

[White Wolf]

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

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

 

[Ron Natalie]

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?

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]

tom_usenet wrote:
[SNIP]

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

Initialization is the action.
Ok

An action of giving a determined value to
some object.

Who says? Not the standard.

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

A a(1); // initialized? yes. determinate value? no.

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

Your definition of initialized is wrong. e.g. 6.7/2
"Variables with automatic storage duration (3.7.2) are initialized
each time their declaration­statement 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).

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. Here is an example
of just that (from 8.5.1/8):

"An empty initializer­list 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, "initialized" means "initialized by the compiler/runtime",
whereas the "uninitialized" means "not directly initialized by an
initializer".

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

 

[tom_usenet]

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.

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.

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? I don't
think the standard backs you on this!

Tom

 

[jeffc]

"jeffc" <[email protected]> wrote in message
There are plenty of things you can put in the initializer list.
You can put functions, additions, conditon logic, and more.

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]

Same way you call any other function.

Yeah, right.

 

[jeffc]

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

 

[tom_usenet]

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:

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]

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]

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.

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

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­list 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, "initialized" means "initialized by the compiler/runtime",
whereas the "uninitialized" means "not directly initialized by an
initializer".

Ahha! So basically they *are not* initialized.

Ahh, yes, although it might be useful to allow it to fall under 4.1 by
changing the language in both places to "inderminate 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.

 

[White Wolf]

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.

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.

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.

 

[tom_usenet]

Common sense? Sanity? Logic? Vulcans?


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

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++?

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.

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?

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.

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.

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*):perator 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]

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.

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

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" ;-)

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*):perator 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.

 

[jeffc]

I think you completely misunderstood him:

Maybe so.

 

[Kevin Goodsell]

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

 

[Alf P. Steinbach]

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

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

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

 

[White Wolf]

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.

 

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