Re: class object initialisation
tom_usenet wrote:[color=blue][color=green]
>> 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.[/color]
Well, in my poor English vocabulary that is non-determinable. Indeterminate
is (for me) something we do not know for sure (like what will rand put
there) but we can find out later. Non-determinable is OTOH something which
cannot be examined.
But this whole point is mute: that very POD may not even conform to its own
requirements. The "value" there is *not* necessarily a value for that type,
hence it is not initialized.
[color=blue]
> 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]
I dunno much about that abstract machine, but IMHO it makes much more sense
to say that it is not initialized. Because that is what happens. It is
assigned memory (it will become existing as an object - in the C meaning)
but it is not initialized.
[color=blue][color=green][color=darkred]
>>> 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.[/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) .[/color]
Where is that required by the standard?
[color=blue]
> 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.[/color]
The standard seems to mix existing with initialized...
[color=blue]
> This is
> useful elsewhere though: invalid pointers do have indeterminate
> values, according to the note in 5.3.5/4.[/color]
Again a bit of a mystery. delete take a *copy* of the pointer. So it
cannot change it at all. So the value of the pointer *is* determined, we
exactly know what value it has. Only this value is not to be dereferenced.
[color=blue]
> 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".[/color]
Singular I like. :-) Let's bet on this one. It is stunning enough that I
will stop seeing things like this in code:
zzz f2( bool &b, YYY y) {
if (y.w() != 32) return;
...
}
XXX f(YYY y) {
bool b;
ZZZ z = f2(b, y);
if (b) {
...
} else {
...
}
}
[color=blue]
> Is it really useful to talk about uninitialized
> PODs then, rather than ones with indeterminate values?[/color]
Yes. "Indetermin ate value" implies: it is an int, but with some garbage
value in it; while the truth is: it is a place for an int, with no int in
it.
--
Attila aka WW
tom_usenet wrote:[color=blue][color=green]
>> 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.[/color]
Well, in my poor English vocabulary that is non-determinable. Indeterminate
is (for me) something we do not know for sure (like what will rand put
there) but we can find out later. Non-determinable is OTOH something which
cannot be examined.
But this whole point is mute: that very POD may not even conform to its own
requirements. The "value" there is *not* necessarily a value for that type,
hence it is not initialized.
[color=blue]
> 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]
I dunno much about that abstract machine, but IMHO it makes much more sense
to say that it is not initialized. Because that is what happens. It is
assigned memory (it will become existing as an object - in the C meaning)
but it is not initialized.
[color=blue][color=green][color=darkred]
>>> 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.[/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) .[/color]
Where is that required by the standard?
[color=blue]
> 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.[/color]
The standard seems to mix existing with initialized...
[color=blue]
> This is
> useful elsewhere though: invalid pointers do have indeterminate
> values, according to the note in 5.3.5/4.[/color]
Again a bit of a mystery. delete take a *copy* of the pointer. So it
cannot change it at all. So the value of the pointer *is* determined, we
exactly know what value it has. Only this value is not to be dereferenced.
[color=blue]
> 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".[/color]
Singular I like. :-) Let's bet on this one. It is stunning enough that I
will stop seeing things like this in code:
zzz f2( bool &b, YYY y) {
if (y.w() != 32) return;
...
}
XXX f(YYY y) {
bool b;
ZZZ z = f2(b, y);
if (b) {
...
} else {
...
}
}
[color=blue]
> Is it really useful to talk about uninitialized
> PODs then, rather than ones with indeterminate values?[/color]
Yes. "Indetermin ate value" implies: it is an int, but with some garbage
value in it; while the truth is: it is a place for an int, with no int in
it.
--
Attila aka WW
Comment