Setting every bit in all members of a class to 0

[Spoon]

Hello everyone,

Consider a class with many integer members.
I want to set every bit in all members to 0 in the constructor.

struct Foo
{
Foo() { memset(this, 0, sizeof *this); }
int a, b, c, d, e, f, g, h, i, j, k;
};

Is it safe to use memset this way in this situation?

Regards.

 

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

Hello everyone,

Consider a class with many integer members.
I want to set every bit in all members to 0 in the constructor.

struct Foo
{
Foo() { memset(this, 0, sizeof *this); }
int a, b, c, d, e, f, g, h, i, j, k;

};

Is it safe to use memset this way in this situation?

Perhaps in this case, but in general no. If you have members of non-
POD types you can get a lot of problems.

 

[Pietro Cerutti]

Hello everyone, Hello,


Consider a class with many integer members.
I want to set every bit in all members to 0 in the constructor.

struct Foo
{
Foo() { memset(this, 0, sizeof *this); }
int a, b, c, d, e, f, g, h, i, j, k;

};

Is it safe to use memset this way in this situation?

I don't see any argument not to do so...

Regards.

Regards

 

[Ivan Vecerina]

: Consider a class with many integer members.
: I want to set every bit in all members to 0 in the constructor.
:
: struct Foo
: {
: Foo() { memset(this, 0, sizeof *this); }
: int a, b, c, d, e, f, g, h, i, j, k;
: };
:
: Is it safe to use memset this way in this situation?

Formally, this triggers undefined behavior according to
the C++ standard - unfortunately.
It is illegal to "overwrite" a non-POD type using memset,
and having a constructor means that Foo is not POD.
There are proposals for C++0x to formally allow this
(by making sub-categories of "POD" types).

In practice, it is likely to behave as expected in this
simple case (memset would obviously be bad if Foo had
a virtual member, or a base class with such a member).

Unfortunately, in the constructor, there is no simple
and portable way to automatically initialize members of
built-in types to a default value. I am not aware of any
formally portable shortcut to avoid the error-prone
listing of every member in the initialization-list:
Foo():a(0),b(0),c(0),d(0),e(0),f(0),g(0),h(0),i(0),j(0),k(0){}

However, some compilers or source-checking tools may
provide warnings if only a subset of members is listed
in an initialization-list.


I hope this helps,
Ivan

 

[Alf P. Steinbach]

* Ivan Vecerina:

: Consider a class with many integer members.
: I want to set every bit in all members to 0 in the constructor.
:
: struct Foo
: {
: Foo() { memset(this, 0, sizeof *this); }
: int a, b, c, d, e, f, g, h, i, j, k;
: };
:
: Is it safe to use memset this way in this situation?

Formally, this triggers undefined behavior according to
the C++ standard - unfortunately.
It is illegal to "overwrite" a non-POD type using memset,
and having a constructor means that Foo is not POD.
There are proposals for C++0x to formally allow this
(by making sub-categories of "POD" types).

In practice, it is likely to behave as expected in this
simple case (memset would obviously be bad if Foo had
a virtual member, or a base class with such a member).

Unfortunately, in the constructor, there is no simple
and portable way to automatically initialize members of
built-in types to a default value. I am not aware of any
formally portable shortcut to avoid the error-prone
listing of every member in the initialization-list:
Foo():a(0),b(0),c(0),d(0),e(0),f(0),g(0),h(0),i(0),j(0),k(0){}

struct FooPOD { int a, b, c, d, e, f, g, h, i j k; };
struct Foo: FooPOD { Foo(): FooPOD() {} };

 

[Jim Langston]

Hello everyone,

Consider a class with many integer members.
I want to set every bit in all members to 0 in the constructor.

struct Foo
{
Foo() { memset(this, 0, sizeof *this); }
int a, b, c, d, e, f, g, h, i, j, k;
};

Is it safe to use memset this way in this situation?

This was done quite a bit in C. I was working on some code in C converting
it to C++. One thing I wanted to do was to add a class with a constructor
to structure. Which broke. And I couldn't figure out why. Then I finally
tracked it down to a memset type of issue( it was different, but similar).

Consdier you class.

struct Foo
{
Foo() { memset( this, 0, sizeof *this ); }
int a,b,c,de,f,g,j,i,j,k;
};

Later you decide to store a name in this so you add a std::string.

struct Foo
{
Foo() { memset( this, 0, sizeof *this ); }
int a,b,c,de,f,g,j,i,j,k;
std::string Name;
};

Now Name won't work. It'll cause memory segmentation faults and such when
you try to access it. Can you figure out why? Because all the ponters
stored in Name when it has been constructed have been set to 0, effectively
becoming NULL pointers (on some systems) losing the memory they pointed to,
along with other data they need.

memset of a structure or class is a BAD thing.

 

[ldh]

I am not aware of any

formally portable shortcut to avoid the error-prone
listing of every member in the initialization-list:
Foo():a(0),b(0),c(0),d(0),e(0),f(0),g(0),h(0),i(0),j(0),k(0){}

A little class like this one can be useful for classes where this is
an issue:

//auto-initialize POD types as well as class types
template<typename T>
struct auto_zero {
T data;
operator T&() {return data;}
operator T const&() const {return data;}

auto_zero(T const& d) : data(d) {}
auto_zero() : data() {}
};

This is probably fairly similar to boost::value_initialized also. I've
sometimes also found it convenient to partially specialize for
pointers:

template<typename T>
struct auto_zero<T*> {
T* data;
operator T*&() {return data;}
operator T* const&() const {return data;}

T& operator*() const {return *data;}
T* operator->() const {return data;}

auto_zero(T *const d) : data(d) {}
auto_zero() : data() {}
};

Anyway the idea is, instead of

struct A {
int i,j,k,l,m;
A() : i(), j(), k(), l(), m() {}
};

which can easily become a maintenance problem, you just do

struct A {
auto_zero<int> i,j,k,l,m;
};

The automatic conversions make this completely transparent pretty much
99% of the time, occasionally you need an explicit cast, such as if
you want to use one of the variables in a switch statement.

-Lewis