memset on structs with non-PODs

[Patrick Kowalzick]

Dear all,

I have an existing piece of code with a struct with some PODs.

struct A
{
int x;
int y;
};

This struct is created somewhere and initialized via a memset.

A a;
memset(&a,0,siz eof(A));

Now I want to extend the structure with an object, e.g a vector:

struct A
{
int x;
int y;
std::vector<int > z;
};

The sequence

A a;
memset(&a,0,siz eof(A));

would be fatal now, because I overwrite the instanciated vector a.z.
In reality the struct is very huge with a bunch of PODs inside, so using a
ctor would be possible, but quite a lot of work. (I am also scared to miss
something). How would you proceed to avoid the devastating memset?
I thought of kind of

struct A
{
int x;
int y;
int no_memsetbeyond _this_point;
std::vector<int > z;
};

and

A a;
memset(&a,0,&a. no_memsetbeyond _this_point-&a);

It is not really nice, but I have to avoid as much code-rework as possible
for the moment.

Kind regards,
Patrick

[Bo Persson]

"Patrick Kowalzick" <pa************ ***@mapandguide .de> skrev i
meddelandet news:ne******** ************@pr oxy.mapandguide .de...

Hello Bo,

Perfect. Thats a rather good solution. Anyway for this case I will
change to

struct PodA
{
PodA() { memset(this,0,s izeof(PodA)); }
...
};

But now you have a constructor, so it's not a POD anymore. :-(

Hmm, ok. I call it "public class with only PODs inside" :).

Ok, I didn't explain it properly:

If it's not a POD, you cannot use memset() on it.
That was the original problem! :-)
Bo Persson

[Patrick Kowalzick]

Hello Bo,

Hmm, ok. I call it "public class with only PODs inside" :).
Ok, I didn't explain it properly:

If it's not a POD, you cannot use memset() on it.

Why not? I will take a look in the standard, now, but I was quite sure, that
adding a function to POD-struct will not change the memory structure of this
struct. I see no obvious reason, why this should be dangerous.

If it is dangerous there is still the soution Zara suggests...
That was the original problem! :-)

Not really. The problem was an inner class, which itself may initialize,
inside a structure which is overwirtten by a memset on the outer struct. The
initialization of the inner class is lost (and even worse the instance might
be invalid).

Kind regards,
Patrick

[Patrick Kowalzick]

>>> Hmm, ok. I call it "public class with only PODs inside" :).

Ok, I didn't explain it properly:

If it's not a POD, you cannot use memset() on it.

Why not? I will take a look in the standard, now, but I was quite sure,
that adding a function to POD-struct will not change the memory structure
of this struct. I see no obvious reason, why this should be dangerous.

I think, a class with a ctor can still be a POD-class. There fore two cites
from the standard:

"(3.9.10) Arithmetic types (3.9.1), enumeration types, pointer types, and
pointer to member types (3.9.2), and cv-qualified versions of these types
(3.9.3) are collectively called scalar types. Scalar types, POD-struct
types, POD-union types (clause 9), arrays of such types and cv-qualified
versions of these types (3.9.3) are collectively called POD types."

"(9.0.4) {...} A POD-struct is an aggregate class that has no non-static
data members of type non-POD-struct, non-POD-union (or array of such types)
or reference, and has no user-defined copy assignment operator and no
user-defined destructor. Similary, a POD-union is an aggregate union that
has no non-static data members of type non-POD-struct, non-POD-union (or
array of such types) or reference, and has no user-defined copy assignment
operator and no user-defined destructor. A POD class is a class that is
either a POD-struct or a POD-union."

I have no other non-POD typed, nor a copy assignment, nor a dtor. So it is
still a POD? But what about a vtable? Might this still be a POD?

Regards,
Patrick

[Patrick Kowalzick]

> I think, a class with a ctor can still be a POD-class. There fore two

cites from the standard:
Bullshit :).
"(3.9.10) Arithmetic types (3.9.1), enumeration types, pointer types, and
pointer to member types (3.9.2), and cv-qualified versions of these types
(3.9.3) are collectively called scalar types. Scalar types, POD-struct
types, POD-union types (clause 9), arrays of such types and cv-qualified
versions of these types (3.9.3) are collectively called POD types."

"(9.0.4) {...} A POD-struct is an aggregate class that has no non-static
data members of type non-POD-struct, non-POD-union (or array of such
types) or reference, and has no user-defined copy assignment operator and
no user-defined destructor. Similary, a POD-union is an aggregate union
that has no non-static data members of type non-POD-struct, non-POD-union
(or array of such types) or reference, and has no user-defined copy
assignment operator and no user-defined destructor. A POD class is a class
that is either a POD-struct or a POD-union."

I have no other non-POD typed, nor a copy assignment, nor a dtor. So it is
still a POD? But what about a vtable? Might this still be a POD?

"[8.5.1.1] An aggregate is an array or a class (clause 9) with no
user-declared constructors (12.1), no private or protected non-static data
members (clause 11), no base classes (clause 10), and no virtual functions
(10.3)."

And for sure, read the FAQ:
http://www.parashift.com/c++-faq-lit....html#faq-26.7

Thanks all a lot for you input in this thread. I hope I got it now.

Kind regards,
Patrick

[Patrick Kowalzick]

Hello Alf,

For now, rename the orginal struct to PodA,

struct PodA { ... };

then derive struct A from that,

struct A: PodA
{
A(): PodA() {}
std::vector<int > z;
};

and also check that your compiler supports default-initialization of
POD's (unfortunately some don't).

I checked this. Some of my compilers support default-initialization, some
not :(. This is really sad.

So I use now this here (even if there is a difference to memset in the
result):

struct A_PODs{ ... };

struct A : public A_PODs
{
A()
{
static A_PODs zero_init = { 0 };
// static A_PODs zero_init = { }; // would be enough, but does not
work on all compilers.
*(static_cast< A_PODs * >(this)) = zero_init; // is this safe?
}
};
Kind regards,
Patrick