Memory initialization

[mcassiani]

Hi,

I need to zero init a class with many variables (members),
what is the best method to do it withoun init separately each members.

es:

class test{
int a1;
..
...
int a100
char v1[100]
...
ichar v100[100]
}

Marco

[JustSomeGuy]

mcassiani wrote:

Hi,

I need to zero init a class with many variables (members),
what is the best method to do it withoun init separately each members.

es:

class test{
int a1;
..
..
int a100
char v1[100]
...
ichar v100[100]
}

Marco

Although this might be dangerous you might try using memset or bzero
functions using the sizeof(class test) as a paramters...
I belive this is not a very 'object' oriented approach...

a1 = a100 = v1 = v100 = 0; // should work as well...

[Martin M. Pedersen]

"JustSomeGuy" <No***@ucalgary.ca> wrote in message
news:40***************@ucalgary.ca...

I need to zero init a class with many variables (members),

Although this might be dangerous you might try using memset or bzero
functions using the sizeof(class test) as a paramters...
I belive this is not a very 'object' oriented approach...

If the class is a POD structure, as it seems to be in this case, memset()
would be my solution too. On the other hand, if it is really a class -
perhaps with a vtable - copying a static instance with zero values works
better (read: memset() does not work if there is a vtable).

Regards,
Martin M. Pedersen

[Ioannis Vranos]

mcassiani wrote:

Hi,

I need to zero init a class with many variables (members),
what is the best method to do it withoun init separately each members.

es:

class test{
int a1;
..
...
int a100
char v1[100]
...
ichar v100[100]
}

Marco

If members are public:
class test
{
public:

int a1, a2;

char v1[100], v2[100];
};
int main()
{
test whatever={0,0, {0}, {0}};
}

The same apply for a struct.

For private members you will have to use a constructor.


Best regards,

Ioannis Vranos

[Peter Koch Larsen]

"Martin M. Pedersen" <noname> skrev i en meddelelse
news:40*********************@dread11.news.tele.dk. ..

"JustSomeGuy" <No***@ucalgary.ca> wrote in message
news:40***************@ucalgary.ca...

I need to zero init a class with many variables (members), Although this might be dangerous you might try using memset or bzero
functions using the sizeof(class test) as a paramters...
I belive this is not a very 'object' oriented approach...

If the class is a POD structure, as it seems to be in this case, memset()
would be my solution too. On the other hand, if it is really a class -
perhaps with a vtable - copying a static instance with zero values works
better (read: memset() does not work if there is a vtable).

memset just does not work for floating point types. Thus my recommendation
is to use standard constructors and expect the optimizer to be intelligent
enough to do a memset if that is the proper thing to do.

/Peter

Regards,
Martin M. Pedersen

[JustSomeGuy]

Peter Koch Larsen wrote:

"Martin M. Pedersen" <noname> skrev i en meddelelse
news:40*********************@dread11.news.tele.dk. ..

"JustSomeGuy" <No***@ucalgary.ca> wrote in message
news:40***************@ucalgary.ca...

> I need to zero init a class with many variables (members),
Although this might be dangerous you might try using memset or bzero
functions using the sizeof(class test) as a paramters...
I belive this is not a very 'object' oriented approach...
If the class is a POD structure, as it seems to be in this case, memset()
would be my solution too. On the other hand, if it is really a class -
perhaps with a vtable - copying a static instance with zero values works
better (read: memset() does not work if there is a vtable).

memset just does not work for floating point types. Thus my recommendation
is to use standard constructors and expect the optimizer to be intelligent
enough to do a memset if that is the proper thing to do.

VERY TRUE.


/Peter

Regards,
Martin M. Pedersen

[Dave Townsend]

If you need to do something like this, you might be doing things the
hard way!
"mcassiani" <mc*******@virgilio.it> wrote in message
news:Mu***********************@news4.tin.it...

Hi,

I need to zero init a class with many variables (members),
what is the best method to do it withoun init separately each members.

es:

class test{
int a1;
..
..
int a100
char v1[100]
...
ichar v100[100]
}

Marco

[David Rubin]

Ioannis Vranos <iv*@guesswh.at.grad.com> wrote in message news:<ca**********@ulysses.noc.ntua.gr>...

mcassiani wrote:

Hi,

I need to zero init a class with many variables (members),
what is the best method to do it withoun init separately each members.

es:

class test{
int a1;
..
...
int a100
char v1[100]
...
ichar v100[100]
}

Marco

If members are public:
class test
{
public:

int a1, a2;

char v1[100], v2[100];
};
int main()
{
test whatever={0,0, {0}, {0}};
}

test t = {0};

will suffice. If you need to re-initialize a test instance to all
zeros, something like

test z = {0};
test t;

// ...

t = z;

works well. As you point out, if test has private members, or non-POD
members, you need to implement various constructors. If you have many
private data elements in a class, it may be worthwhile to partially
insulate the class as

// test.h
class test_i; // private members, defined in test.cpp
class test {
test_i *d_this;
public:
test(); // non-inline definition allocates test_i
~test() { delete d_this; }
// rest of public interface
};

Then, inside test.cpp, you can use the above technique to initialize
*d_this to zeros.

/david

[Siemel Naran]

"Peter Koch Larsen" <pk*****@mailme.dk> wrote in message news:09oAc.14753

memset just does not work for floating point types. Thus my recommendation
is to use standard constructors and expect the optimizer to be intelligent
enough to do a memset if that is the proper thing to do.

Just curious. If all the bits of a double are zero, then what is the value
of the double? It's not necessarily zero? What do some implementations do?

[Siemel Naran]

"mcassiani" <mc*******@virgilio.it> wrote in message news:MulAc.487973

I need to zero init a class with many variables (members),
what is the best method to do it withoun init separately each members.

es:

class test{
int a1;
..
..
int a100
char v1[100]
...
ichar v100[100]
}

Fundamental types at global or class static scopes are zero initialized. An
array or struct consisting of fundamental types or other such structs also
qualifies. Thus I think the following should work. It works on my
compiler, and maybe will work on all:

class test{
public:
test() { *this = zero; }
int a;
double b;
private:
class NoInitialize { };
test(NoInitialize) { }
static test zero;
};

test test::zero;

[Ioannis Vranos]

JustSomeGuy wrote:

Although this might be dangerous you might try using memset

memset() can only be used to unsigned chars since any other type may
contain padding bits.

or bzero

What is bzero?
functions using the sizeof(class test) as a paramters...
I belive this is not a very 'object' oriented approach...

a1 = a100 = v1 = v100 = 0; // should work as well...

With v1, v100 being arrays this should not work.


Best regards,

Ioannis Vranos

[Ioannis Vranos]

Siemel Naran wrote:

Just curious. If all the bits of a double are zero, then what is the value
of the double? It's not necessarily zero? What do some implementations do?

It is implementation dependent.


Best regards,

Ioannis Vranos

[Siemel Naran]

"Ioannis Vranos" <iv*@guesswh.at.grad.com> wrote in message

memset() can only be used to unsigned chars since any other type may
contain padding bits.

So what? You can set the padding bits to zero too!

[Ioannis Vranos]

Siemel Naran wrote:

"Ioannis Vranos" <iv*@guesswh.at.grad.com> wrote in message

memset() can only be used to unsigned chars since any other type may
contain padding bits.

To make my statement above more precise:

"memset() can only be used to unsigned chars since any other type may
contain (bytes with) padding bits."



So what? You can set the padding bits to zero too!

And then we get undefined behaviour.


Best regards,

Ioannis Vranos

[Ioannis Vranos]

Ioannis Vranos wrote:

To make my statement above more precise:

"memset() can only be used to unsigned chars

and chars, signed chars (since stand alone signed chars can have the
value 0)

since any other type may
contain (bytes with) padding bits."

So what? You can set the padding bits to zero too!

And then we get undefined behaviour.

Best regards,

Ioannis Vranos

[Ioannis Vranos]

Ioannis Vranos wrote:

Ioannis Vranos wrote:

To make my statement above more precise:

"memset() can only be used to unsigned chars

and chars, signed chars (since stand alone signed chars can have the
value 0)

since any other type may contain (bytes with) padding bits."

And in a strive for perfection let me rearrange my statement:
"memset() in general, can only be used to chars, signed chars and
unsigned chars, since these as stand alone types can have the value 0,
while any other type may contain bytes with padding bits (which means
bytes with non-zero values)."
Changing the value of padding bits produces undefined behaviour.


Best regards,

Ioannis Vranos

[Ioannis Vranos]

Rearranged again (for *last time* I promise!) :-)
memset() in general, can only be used to chars, signed chars and
unsigned chars, since these as stand alone types can have the value 0,
while any other type may contain bytes with padding bits.

Changing the value of padding bits, even if it is the same value,
produces undefined behaviour.


Best regards,

Ioannis Vranos

[JKop]

Ioannis Vranos posted:

Changing the value of padding bits, even if it is the same value,
produces undefined behaviour.

Petting an animal has undefined behaviour. People still do it though.

I myself wouldn't pay a blind bit of notice to changing padding bits. Is
there an actual statement from the Standard that you can quote that
explicitly states your argument?
-JKop

[Ioannis Vranos]

JKop wrote:

Ioannis Vranos posted:

Changing the value of padding bits, even if it is the same value,
produces undefined behaviour.

I myself wouldn't pay a blind bit of notice to changing padding bits. Is
there an actual statement from the Standard that you can quote that
explicitly states your argument?

As far as I know the standard mentions nothing regarding changing the
value of padding bits.

Perhaps a better terminology would be "system-dependent" behaviour.

In any case, it is *not* a well-defined behaviour.


Best regards,

Ioannis Vranos

[Ioannis Vranos]

Ioannis Vranos wrote:

JKop wrote:

Ioannis Vranos posted:

Changing the value of padding bits, even if it is the same value,
produces undefined behaviour.

I myself wouldn't pay a blind bit of notice to changing padding bits.
Is there an actual statement from the Standard that you can quote that
explicitly states your argument?

As far as I know the standard mentions nothing regarding changing the
value of padding bits.

Perhaps a better terminology would be "system-dependent" behaviour.

In any case, it is *not* a well-defined behaviour.

.... in general. There are special cases where *the same value* of
padding bits can be written as in the case of POD types:
"For any complete POD object type T, whether or not the object holds a
valid value of type T, the underlying
bytes (1.7) making up the object can be copied into an array of char or
unsigned char.36) If the content
of the array of char or unsigned char is copied back into the object,
the object shall subsequently
hold its original value.

[Example:
#define N sizeof(T)
char buf[N];
T obj; // obj initialized to its original value
memcpy(buf, &obj, N); // between these two calls to memcpy,
// obj might be modified
memcpy(&obj, buf, N); // at this point, each subobject of obj of scalar type
// holds its original value
—end example]
3 For any POD type T, if two pointers to T point to distinct T objects
obj1 and obj2, if the value of obj1
is copied into obj2, using the memcpy library function, obj2 shall
subsequently hold the same value as
obj1. [Example:
T* t1p;
T* t2p;
// provided that t2p points to an initialized object ...
memcpy(t1p, t2p, sizeof(T)); // at this point, every subobject of POD
type in *t1p contains
// the same value as the corresponding subobject in *t2p
—end example]

4 The object representation of an object of type T is the sequence of N
unsigned char objects taken up by
the object of type T, where N equals sizeof(T). The value representation
of an object is the set of bits
that hold the value of type T. For POD types, the value representation
is a set of bits in the object representation
that determines a value, which is one discrete element of an
implementationdefined
set of values.37)"


However as it can be seen in the last paragraph, for non-POD types we
can only *read* the objects as arrays of unsigned chars.


Best regards,

Ioannis Vranos

[Siemel Naran]

"Ioannis Vranos" <iv*@guesswh.at.grad.com> wrote in message news:caubvp$13d2

As far as I know the standard mentions nothing regarding changing the
value of padding bits.

Perhaps a better terminology would be "system-dependent" behaviour.

In any case, it is *not* a well-defined behaviour.

What do you mean by not well-defined?

... in general. There are special cases where *the same value* of
padding bits can be written as in the case of POD types:
"For any complete POD object type T, whether or not the object holds a
valid value of type T, the underlying
bytes (1.7) making up the object can be copied into an array of char or
unsigned char.36) If the content
of the array of char or unsigned char is copied back into the object,
the object shall subsequently
hold its original value.

[Example:
#define N sizeof(T)
char buf[N];
T obj; // obj initialized to its original value
memcpy(buf, &obj, N); // between these two calls to memcpy,
// obj might be modified
memcpy(&obj, buf, N); // at this point, each subobject of obj of scalar type // holds its original value
—end example]
3 For any POD type T, if two pointers to T point to distinct T objects
obj1 and obj2, if the value of obj1
is copied into obj2, using the memcpy library function, obj2 shall
subsequently hold the same value as
obj1. [Example:
T* t1p;
T* t2p;
// provided that t2p points to an initialized object ...
memcpy(t1p, t2p, sizeof(T)); // at this point, every subobject of POD
type in *t1p contains
// the same value as the corresponding subobject in *t2p
—end example]

4 The object representation of an object of type T is the sequence of N
unsigned char objects taken up by
the object of type T, where N equals sizeof(T). The value representation
of an object is the set of bits
that hold the value of type T. For POD types, the value representation
is a set of bits in the object representation
that determines a value, which is one discrete element of an
implementationdefined
set of values.37)"


However as it can be seen in the last paragraph, for non-POD types we
can only *read* the objects as arrays of unsigned chars.

What do these last 4 quotes have to do with padding? BTW, padding might be
addressed more fully in the C standard library, but I don't have that one.

[Ioannis Vranos]

Siemel Naran wrote:

In any case, it is *not* a well-defined behaviour.

What do you mean by not well-defined?

I mean that if you change the padding bits of an object, the program may
crash for example.

What do these last 4 quotes have to do with padding? BTW, padding might be
addressed more fully in the C standard library, but I don't have that one.

They are the only which describe special cases which may include padding
bits. From these quotes we can conclude that it is guaranteed to be safe
writing on padding bits belonging to POD types, but only their existing
values.

And it is guaranteed to be safe to read padding bits from both POD and
non-POD types, in the first case using char or unsigned char pointers
and in the second case only unsigned char pointers.
These are the only guarantees provided by the standard on padding bits.
Everything else produces non-well-defined behaviour.


Regards,

Ioannis Vranos