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

[Alf P. Steinbach]

* 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;
};
When you have public non-POD members you need to redesign.

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?

When you a "very huge" struct you need to redesign.

But possibly you need to practice that on some smaller test programs
first.

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

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Patrick Kowalzick]

Hello Alf,

struct A
{
int x;
int y;
std::vector<int > z;
};
When you have public non-POD members you need to redesign.

Normally I'd never use struct for more complex things :).

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?

When you a "very huge" struct you need to redesign.

Hmm, might be. Lets say very huge in this context is nothing elses than: I
do not want to initialize all the members.
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;
};
Perfect. Thats a rather good solution. Anyway for this case I will change to

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

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

This is not nice (ok it is ugly), but closer to the original code.
and also check that your compiler supports default-initialization of
POD's (unfortunately some don't).

I can not, as support for different compiliers has to be assured.

Thanks, that's really good solution.

Regards,
Patrick

[Zara]

On Thu, 19 Jan 2006 14:57:34 +0100, "Patrick Kowalzick"
<pa************ ***@mapandguide .de> wrote:

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,si zeof(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,si zeof(A));

would be fatal now, because I overwrite the instanciated vector a.z.

<snip>

You may create a non-virtual base class with only POD data and inherit
from it. In such a way, you could still a memset, but only with thiis
base class.

struct A_
{
int x;
int y;
};

struct A:public A_
{
A() {memset(static_ cast<A_ *>(this),0,size of(A_);}
std::vector<int > z;
};

Regards,

Zara

[Maxim Yegorushkin]

Patrick Kowalzick wrote:

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.

[]

Overload memset() in the same header where A is declared:

void memset(A*, int, size_t);

Note that this overload won't be called if memset is invoked as:

memset(void*)&a , ...);

A more proper way would be to redesign the code, so that it don't do
memset on A's anymore.

[ma740988]

Alf P. Steinbach wrote:

* 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;
};

I have a follow on question to this. Given:

unsigned int const max_id = 5;
unsigned int const max_participant s = 5;
struct some_struct
{ int some_param;
some_struct()
: some_param( -1) {}
};

struct some_other_stru ct
{ int some_var;
int some_size;
unsigned char* ptr;
some_other_stru ct()
: some_var(-1)
, some_size(-1)
, ptr(0)
{}
};

struct someImportantDa ta {
unsigned int c_style_arr[ max_participant s ];
some_struct c_style_arr2[ max_id ] [ max_participant s ];
some_other_stru ct c_style_arr3[ max_participant s ];
};
int main()
{
someImportantDa ta sid;
for ( int idx(0); idx < max_participant s; ++idx )
{
sid.c_style_arr[ idx ] = idx ;
}
typedef std::vector<uns igned int> UINT_VEC;
UINT_VEC myVec(&sid.c_st yle_arr[0],
&sid.c_style_ar r[max_participant s] );

UINT_VEC::itera tor end = myVec.end();
for ( UINT_VEC::const _iterator it = myVec.begin(); it != end; ++it )
{
std::cout << *it << std::endl;
}

}

Now going from c_style_arr to a vector is easy (as shown below) .
How would I do the c_style_arr2 and c_style_arr3? Part of the issue
with c_sytle_arr2 is based on the fact that I'm still experimenting
with 2-d vectors.

In any event, thanks in advance.

[Patrick Kowalzick]

Hello Maxim,

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.

[]

Overload memset() in the same header where A is declared:

void memset(A*, int, size_t);

Note that this overload won't be called if memset is invoked as:

memset(void*)&a , ...);

A more proper way would be to redesign the code, so that it don't do
memset on A's anymore.

The memset are not too often, so I kicked them :). But it seems to be a good
idea to overload memset, perhaps I missed one.....

void memset(A*, int, size_t)
{
assert( "Please, please do not use memset for this struct");
}

Hmm, or static_assert? Would something like this work as static assert?

// forward for allowed memsets
template < typename T > class memset_functor
{
public:
void * operator()( T* dest, int c, size_t count )
{
return memset(dest,c,c ount);
}
};

// forward for disallowed memsets
template <> class memset_functor< A >
{
public:
void * operator()( A *, int, size_t )
{
// STATIC_ASSERTIO N
}
};

template < typename T >
void * memset( T* dest, int c, size_t count )
{
return memset_functor< T>()(dest,c,cou nt);
}

Looks funny. I will test this towmorrow :)

Regards,
Patrick

[Bo Persson]

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

Hello Alf,

struct A
{
int x;
int y;
std::vector<int > z;
};
When you have public non-POD members you need to redesign.

Normally I'd never use struct for more complex things :).

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?

When you a "very huge" struct you need to redesign.

Hmm, might be. Lets say very huge in this context is nothing elses
than: I do not want to initialize all the members.

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;
};

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. :-(

This is not nice (ok it is ugly), but closer to the original code.

It is ugly!
Bo Persson

[Patrick Kowalzick]

> Hmm, or static_assert? Would something like this work as static assert?

// forward for allowed memsets
template < typename T > class memset_functor
{
public:
void * operator()( T* dest, int c, size_t count )
{
return memset(dest,c,c ount);
}
};

// forward for disallowed memsets
template <> class memset_functor< A >
{
public:
void * operator()( A *, int, size_t )
{
// STATIC_ASSERTIO N
}
};

template < typename T >
void * memset( T* dest, int c, size_t count )
{
return memset_functor< T>()(dest,c,cou nt);
}

Looks funny. I will test this towmorrow :)

Ok. I tried it, and it does not work.

The specialization memset_functor< A > will be instanciated, even if there
is no call "memset(A,int,s ize_t)". Like this the static assertion always
fails.

I use now an easier approach, which works on my compiler, but I am not sure
if it is bullet proof:

template < typename T >
void * memset( TTransferDistli bData2 * dest, T c, size_t count )
{
BOOST_STATIC_AS SERT(FALSE);
return NULL;
}

Calling memset(A,..) fails like this to compile.

Kind regards,
Patrick

[Patrick Kowalzick]

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

This is not nice (ok it is ugly), but closer to the original code.

It is ugly!

no choice.

Regards,
Patrick