class object initialisation

[White Wolf]

Re: class object initialisation

tom_usenet wrote:[color=blue][color=green]
>> 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.[/color]
>
> Indeterminate:
> a)Not precisely determined, determinable, or established: a person of
> indeterminate age.[/color]

He *has* an age, we just do not know it. It is not like he has no such
thing as an age. While uninitialized PODs may have such bits in their
storage that they have no value whatsoever.
[color=blue]
> b)Not precisely fixed, as to extent, size, nature, or number: an
> indeterminate number of plant species in the jungle.[/color]

So many, we cannot/will not count it. Again: it is an existing, valid
value.
[color=blue]
> c)Lacking clarity or precision, as in meaning; vague: an indeterminate
> turn of phrase.[/color]

This - if I understand it properly - is again closer to unknown than to
non-existing (which is the value of an uninitialized POD)
[color=blue]
> d)Not fixed or known in advance: an indeterminate future.[/color]

Again: will be known, only later
[color=blue]
> e)Not leading up to a definite result or ending: an indeterminate
> campaign.[/color]

This meaning is about an action or series of actions. Cannot really be
applied to a value.
[color=blue]
> So indeterminate can mean either not precisely determined or not
> determinable.[/color]

Not determinable from the viewpoint of the observer! BIG difference. The
person of indeterminate age *has* an age. A indeterminate campaign *will*
have an end and a result - if not later than on judgment day.
[color=blue]
> The standard clearly uses it to mean not determinable
> (since you aren't allowed to examine the value).[/color]

I see no such meaning in the listed definitions above. Each and every of
those things above objectively *exist* we just could not, will not, do not
want to determine. OTOH the value of an int, which is built from bits which
makes no sense as an int, is just not there. It does not exist. It is not
an int. There is no sense in talking about it as an int. Since there is no
sense talking about it as an int there is not much sense talking about its
value.
[color=blue][color=green][color=darkred]
>>> There are even more catches to this.
>>>
>>> unsigned char c;
>>> c = c; //legal![/color][/color][/color]

Should not be. c is used as an rvalue there...
[color=blue][color=green][color=darkred]
>>> 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][/color]

Weird! Why would someone ask for such an arbitrary requirement?
[color=blue]
> 3.9.1/1
> Also:
> http://std.dkuug.dk/jtc1/sc22/wg21/d...ctive.html#129[/color]

Hmmmm. This is baaad. I mean this reads: in C++ it is not even not
guaranteed that a variable (POD) has a valid value until it is given one,
but it is not even required to *exist* in its *exclusive* storage... While
I completely agree with what is written in the DR/TR/xR(?) I believe that
this is more than surprising. So not only (real) initialization is optional
but even creation...
[color=blue][color=green][color=darkred]
>>> 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]
>
> It is indeterminate since, although the bit pattern won't have
> changed, valid bit patterns for pointers might have been changed by
> the delete.[/color]

It is not indeterminate. I know what it is. I can determine it. It is
just not valid to be *dereferenced*. I can even store away together with
sand from the Oregon dunes, my childhood golden hair and photos of my late
girlfriend (she is alive, she just never arrives in time) into an in-memory
application log (possibly as a void*). So the pointer has a *valid* value.
I can copy it around. (at lest I hope so). I just cannot dereference it.
If I cannot (even copy it around - which would make sense) then I dunno
enough C++. :-) Which is true, but this would further prove it. BTW I
never did copy it around, only it could make sense for such logging
purposes.

--
WW aka Attila

[foo]

Re: class object initialisation

"jeffc" <nobody@nowhere .com> wrote in message news:<3f65db70_ 2@news1.prserv. net>...[color=blue]
> "foo" <maisonave@axte r.com> wrote in message
> news:c11783b0.0 309131929.a7b14 fe@posting.goog le.com...[color=green]
> > "jeffc" <nobody@nowhere .com> wrote in message[/color]
> news:<3f622fa7_ 4@news1.prserv. net>...[color=green][color=darkred]
> > > "Erik" <no@spam.com> wrote in message news:bjspcn$r22 $1@news.lth.se. ..
> > > > > The basic rule of thumb is that anything that can go in the[/color][/color]
> initialize
> list[color=green][color=darkred]
> > > > > should go there. Obviously, you can't put something like this in[/color][/color]
> there:[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) {}
> > >
> > > 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]
> > 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.[/color]

Why would you want to put functions alone in an initialize list?
The point of the initialize list is to initialize variables. It's not
for replaceing the constructor's function body.
If you have while-loop logic or any other logic that you need for the
initializaiton of your variable, you can easily put that inside a
function that can be used to initialize the member variable.
Example:
class foo
{
public:
foo(const char* Name, int x)
:m_Msg(SomeFunc 1(Name)), m_Data(SomeFunc 2(Name, x))
{
}
const std::string m_Msg;
const std::string m_Data;
private:
std::string SomeFunc1(const std::string &Name){
return "Hello " + Name;
}
std::string SomeFunc2(const std::string &Name, int x)
{
std::string Data;
for (int i = 0;i < x;++i) Data += Name + " ";
return Data;
}
};


int main(int argc, char* argv[])
{
foo MyFoo("Axter", 3);

cout << MyFoo.m_Msg << endl;
cout << MyFoo.m_Data << endl;

system("pause") ;
return 0;
}

[jeffc]

Re: class object initialisation


"foo" <maisonave@axte r.com> wrote in message
news:c11783b0.0 309160950.5cf81 db3@posting.goo gle.com...[color=blue]
> "jeffc" <nobody@nowhere .com> wrote in message[/color]
news:<3f65db70_ 2@news1.prserv. net>...[color=blue][color=green]
> > "foo" <maisonave@axte r.com> wrote in message[color=darkred]
> > > 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[/color][/color]
there,[color=blue][color=green]
> > but you can't put statements in there. You can't call functions[/color][/color]
(alone),[color=blue][color=green]
> > you can't use for or while loops, you can't... well, you already know[/color][/color]
what[color=blue][color=green]
> > you can't do.[/color]
>
> Why would you want to put functions alone in an initialize list?[/color]

Check what you wrote 2 posts ago. You're going around in circles.

[Gary Labowitz]

Re: class object initialisation

"Attila Feher" <attila.feher@l mf.ericsson.se> wrote in message
news:bk757j$i8c $1@newstree.wis e.edt.ericsson. se...[color=blue]
> Gary Labowitz wrote:[color=green]
> > "White Wolf" <wolof@freemail .hu> wrote in message
> > news:bk56j0$4c3 $1@phys-news1.kolumbus. fi...[color=darkred]
> >> 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]
> >
> > Disagree. The type of a variable specifies two things: the size of
> > memory to be accessed and the encoding of the bits in that area.[/color]
>
> Yes.
>[color=green]
> > As far as I know, there are not "invalid" combinations of bits for
> > a type.[/color]
>
> Wrong. There is nothing in the C++ standard which requires this. A
> platform is free to represent an integer on 128 bits with 64 bits for[/color]
value[color=blue]
> and 64 bits for checksum.
>[color=green]
> > Whatever is in there is interpreted according to the encoding
> > of the type.[/color]
>
> It does not necessarily have a meaning. ints aside, this is especially[/color]
true[color=blue]
> with pointers. An implementation is free to encode the pointed type into
> the pointer's bit value.
>[color=green]
> > The value this results in is usually garbage, but is
> > still a value of the type.[/color]
>
> Wrong.
>[color=green]
> > Having said that, I wonder if bool types MUST be either all ones or
> > all zeros.[/color]
>
> Do not wonder. Read the standard. It does not. And indeterminate value
> for a bool does not need to represent either true or false. It is in[/color]
there.[color=blue]
>[color=green]
> > Would a bool containing mixed bits confuse a formatter
> > (like cout) or would it just say "Hmmm, not all zeros --- therefore,
> > true!"[/color]
>
> Implementation defined.[/color]

Thank you. If this be the case, then all my musings are incorrect. Hmm...
check sum bits in a value. Yes, it could. Then invalid bit combinations
could exist. All resulting in undefined behavior I should think.
Back to the drawing board!!!
[Gee, what did we go back to before they invented drawing boards?]
--
Gary

[Gary Labowitz]

Re: class object initialisation

"Attila Feher" <attila.feher@l mf.ericsson.se> wrote in message
news:bk74j1$hr1 $1@newstree.wis e.edt.ericsson. se...[color=blue]
> Gary Labowitz wrote:
> [SNIP][color=green]
> > This looks like fun, so I'll take my stab at it.[/color]
>
> :-) We have way too much time on our hands. ;-)
>[color=green]
> > When a variable is made available to a program,
> > the compiler must have generated code that sets
> > aside some area of memory for use by the
> > program.[/color]
>
> OK. Let's change memory to something what can be written in the[/color]
standard...[color=blue]
> let's call it storage.
>
> Now we have to obfuscate your sentence, since if just anybody could
> understand it (langauge) lawyers (like us ;-) ) would be out of business.
> Variable is for example a very bad name, because programmers actually
> understand what it means. Also it is not appropriate here: the process we
> are going to describe is also applicable to unnamed temporaries, and those
> are not variables.
>
> In C++ the creation of an object is done in two steps, one of which is
> optional for objects of POD types. In the first step appropriate (size,
> alignment) storage is assigned to the object.
>[color=green]
> > If the generated code of the compiler also puts a
> > predetermined value in the area of memory, this is called
> > initialization.[/color]
>
> The second, optional for POD types, step is initialization.
>[color=green]
> > I.e. the memory allocated to the variable, if
> > examined with (say) a cout << operation, will show a value that the
> > programmer specified in the declaration that requested the
> > allocation. However, if the programmer did not specify an initial
> > value in the declaration, all bets are off. The initial value of the
> > variable could be anything and is usually whatever was in the memory
> > area prior to its being used as the variable being declared.[/color]
>
> Without initialization it is not guaranteed that the object represents a
> valid value for its own type, therefore it is results in undefined[/color]
behavior[color=blue]
> (behaviour for Europeans) if the object is used as an rvalue.
>
> Initialization might happen different ways. Initialization can take the
> form of explicit initializer or implicit initialization.
>[color=green]
> > For certain structures, the compiler will zero-initialize members
> > implicitly, without the programmer having to specifically declare an
> > initial value.[/color]
>
> (list cases of implicit initialization)
>[color=green]
> > In the case of arrays, for example, if fewer initial
> > values are provided than the array can store, zero-initialiation will
> > be done for the remaining array elements.
> >
> > Once the variable is available to the program, any movement of a
> > different value into the variable, such as with an assignment
> > operation, is called assignment.[/color]
>
> Storage belonging to objects of POD types might stay in an uninitialized
> from until an initial rvalue of a correct type has been assigned to it.
> [
> int i; // Storage assigned, uninitialized
> int j=i; // Undefined behavior, i is not initialized
> i = 12; // After the ; i is initialized to 12 using assignment
> ]
>[color=green]
> > The entire issue is: What is in the variable immediately
> > after its "creation?"[/color]
>
> An uninitialized object, just like with classes. When the operator new
> returns it points to a well aligned and big enough storage area, but this
> storage area does not yet the conform to the requirements of its final[/color]
type.[color=blue]
>[color=green]
> > If it is a determinate value, specified by the
> > programmer, it has been "initialize d" by the compiler.[/color]
>
> And for PODs this initialization is done by the compiler in the form of
> "first assignment". :-)
>[color=green]
> > [Note: by "memory area" I do not exclude use of registers, data
> > bases, or any other mechanism any given compiler chooses to use for
> > variable storage.][/color]
>
> It is called storage in the standard (for that very reason, that it might
> not be RAM, which we usually think about when we say memory).
>[color=green]
> > Does this make sense to anyone?[/color]
>
> Sort of. :-)[/color]

[Last time fully quoted]
Well, I like your obfuscation! I didn't understand anything! It's ready for
publication!
On the serious side, the fact that there are invalid combinations of bits
for types introduces a whole new complexity for me, and makes the standard
almost unbearably complex. Oh well, reality must be faced.
On the whole, I rather prefer Java: nine simple types to learn about, all
well defined with regard to bit usage and size, no surprises.
Thanks for your patience.
--
Gary

[Gary Labowitz]

Re: class object initialisation

"jeffc" <nobody@nowhere .com> wrote in message
news:3f67716b_1 @news1.prserv.n et...[color=blue]
>
> Check what you wrote 2 posts ago. You're going around in circles.[/color]

It's called a loop.
--
Gary

[Alexander Terekhov]

Re: class object initialisation


White Wolf wrote:
[...][color=blue][color=green][color=darkred]
> >> 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]
> >
> > It is indeterminate since, although the bit pattern won't have
> > changed, valid bit patterns for pointers might have been changed by
> > the delete.[/color]
>
> It is not indeterminate. I know what it is. I can determine it. It is
> just not valid to be *dereferenced*. I can even store away together with
> sand from the Oregon dunes, my childhood golden hair and photos of my late
> girlfriend (she is alive, she just never arrives in time) into an in-memory
> application log (possibly as a void*). So the pointer has a *valid* value.[/color]

Nope.
[color=blue]
> I can copy it around. (at lest I hope so).[/color]

Nope. You can't copy it AS POINTER. std::vector<uns igned char> will
work, though. ;-)

regards,
alexander.

[Attila Feher]

Re: class object initialisation

Alexander Terekhov wrote:[color=blue]
> White Wolf wrote:[color=green]
>> I can copy it around. (at lest I hope so).[/color]
>
> Nope. You can't copy it AS POINTER. std::vector<uns igned char> will
> work, though. ;-)[/color]

Not even as void?

--
Attila aka WW

[Alexander Terekhov]

Re: class object initialisation


Attila Feher wrote:[color=blue]
>
> Alexander Terekhov wrote:[color=green]
> > White Wolf wrote:[color=darkred]
> >> I can copy it around. (at lest I hope so).[/color]
> >
> > Nope. You can't copy it AS POINTER. std::vector<uns igned char> will
> > work, though. ;-)[/color]
>
> Not even as void?[/color]

void pointer? It will also not work. You'll hit undefined
behavior as soon as you try to 'use' deleted/freed pointer
as pointer... assignment of valid pointer value and access
via unsigned char lvalue is totally OK, though. In short,

auto int i; // indeterminate (may be a trap)
auto void * p; // indeterminate (may be a trap)
auto unsigned char c; // indeterminate (unspecified;
// shall NOT be a trap)

IIRC.

regards,
alexander.

[tom_usenet]

Re: class object initialisation

On Wed, 17 Sep 2003 15:40:37 +0300, "Attila Feher"
<attila.feher@l mf.ericsson.se> wrote:
[color=blue]
>Alexander Terekhov wrote:[color=green]
>> White Wolf wrote:[color=darkred]
>>> I can copy it around. (at lest I hope so).[/color]
>>
>> Nope. You can't copy it AS POINTER. std::vector<uns igned char> will
>> work, though. ;-)[/color]
>
>Not even as void?[/color]

This is illegal, even though it isn't dereferenced:

void* p = ::operator new(1);
::operator delete(p);
void* q = p; // boom

You aren't allowed to convert a pointer to an rvalue after deleting
it. You can of course reassign it:
p = 0; //or whatever.

Tom

[Attila Feher]

Re: class object initialisation

Alexander Terekhov wrote:[color=blue]
> Attila Feher wrote:[color=green]
>>
>> Alexander Terekhov wrote:[color=darkred]
>>> White Wolf wrote:
>>>> I can copy it around. (at lest I hope so).
>>>
>>> Nope. You can't copy it AS POINTER. std::vector<uns igned char> will
>>> work, though. ;-)[/color]
>>
>> Not even as void?[/color]
>
> void pointer? It will also not work. You'll hit undefined
> behavior as soon as you try to 'use' deleted/freed pointer
> as pointer...[/color]

But that was the *whole* point: I do *not* want to use it as a pointer. I
never want to dereference it or apply arithmetics to it.

--
Attila aka WW

[Attila Feher]

Re: class object initialisation

tom_usenet wrote:[color=blue][color=green][color=darkred]
>>> Nope. You can't copy it AS POINTER. std::vector<uns igned char> will
>>> work, though. ;-)[/color]
>>
>> Not even as void?[/color]
>
> This is illegal, even though it isn't dereferenced:
>
> void* p = ::operator new(1);[color=green][color=darkred]
>>> operator delete(p);[/color][/color]
> void* q = p; // boom
>
> You aren't allowed to convert a pointer to an rvalue after deleting
> it. You can of course reassign it:
> p = 0; //or whatever.[/color]

Ahha. Makes sense, but quite restrictive. So basically you will need to
store it as "whatever", but not as a pointer if you want to keep the value
around.

--
Attila aka WW

[Alexander Terekhov]

Re: class object initialisation


Attila Feher wrote:
[...][color=blue]
> Ahha. Makes sense, but quite restrictive. So basically you will need to
> store it as "whatever", but not as a pointer if you want to keep the value
> around.[/color]

Even if you store it BEFORE free-ing... since the representation
may have quite a few garbage bits, storing it as "whatever" will
be nothing but "absolutely pointless exercise"... well, just a
few exceptions (I have a patent appl on one of those ;-) ) aside,
of course.

regards,
alexander.

[jeffc]

Re: class object initialisation


"Gary Labowitz" <glabowitz@comc ast.net> wrote in message
news:sjGdnazhm9 rXNfqiXTWJhQ@co mcast.com...[color=blue]
> "jeffc" <nobody@nowhere .com> wrote in message
> news:3f67716b_1 @news1.prserv.n et...[color=green]
> >
> > Check what you wrote 2 posts ago. You're going around in circles.[/color]
>
> It's called a loop.[/color]

Just trying to give the guy a break.
(get it?)

[Attila Feher]

Re: class object initialisation

Alexander Terekhov wrote:[color=blue]
> Attila Feher wrote:
> [...][color=green]
>> Ahha. Makes sense, but quite restrictive. So basically you will
>> need to store it as "whatever", but not as a pointer if you want to
>> keep the value around.[/color]
>
> Even if you store it BEFORE free-ing... since the representation
> may have quite a few garbage bits, storing it as "whatever" will
> be nothing but "absolutely pointless exercise"... well, just a
> few exceptions (I have a patent appl on one of those ;-) ) aside,
> of course.[/color]

Since looking at them later is a "platform dependent exercise" I believe
that whatever garbage bits they have it does not really matter at all.

class DeadPtr {
unsigned char bitz[sizeof(void*)]; // Could be char *
public:
DeadPtr( void const* p) { memcpy and so on}
DeadPtr( void const* const p) { memcpy and so on}
// Something special/platform dependent to display it
};

Off course ;-) this thingy has to be made _before_ the delete is being
called. I dunno if passing as reference counts as use as rvalue... if not
that can be done.

--
Attila aka WW