Clearing structures with member functions.

[roberts.noah]

I ran across some code that called memset(this, 0, sizeof(*this)) in
the member function of a structure in C++. This just looked wrong to
me so I did some web searching and it does indeed seem like a
questionable thing to do. Looking around further took me to a
newsgroup discussion that said the better approach was to do something
like sv = Struct(). The thing is that both cases seem to bo "ok" so
long as there are no virtual functions and no constructor in Struct or
any of its internals. Code like this does not initialize the object to
0:

struct SOut {
int x;
struct SIn {
int y;
SIn : y() {} // or this could be a virtual function...
} in;
}

....

SOut out = SOut(); // initializes y but not x.

out = SOut(); // clears y but not x...

So, since using either approach breaks if given certain circumstances
the question of which is more correct seems unclear. Since this is a
performance issue the real question is which is the faster, memset(x,
0, sizeof(x)) or x = X()? Another question is if the above code should
be clearing the value of x...so long as SIn has no constructor or
virtual functions it works, but as soon as it does the default
constructor of SOut no longer clears x. What law in C++ governs this
behavior?

Is using memset immoral even if you KNOW that the object will never
have any virts? The only reason why I would think it might be is that
these structs have member functions...and calling memset on this
/seems/ icky. I can definately see an argument comming over this and I
would like to be sure of my position...and IANAL.

Thanks.

[Josh Mcfarlane]

ro**********@gm ail.com wrote:

struct SOut {
int x;
struct SIn {
int y;
SIn : y() {} // or this could be a virtual function...
} in;
}

Why not just generate a constructor for SOut then and avoid memset all
together?

-Josh McFarlane

[Mike Wahler]

<ro**********@g mail.com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

I ran across some code that called memset(this, 0, sizeof(*this)) in
the member function of a structure in C++. This just looked wrong to
me so I did some web searching and it does indeed seem like a
questionable thing to do. Looking around further took me to a
newsgroup discussion that said the better approach was to do something
like sv = Struct(). The thing is that both cases seem to bo "ok" so
long as there are no virtual functions and no constructor in Struct or
any of its internals. Code like this does not initialize the object to
0:
And no pointer or floating point members. All-bits-zero is
not guaranteed to evaluate to NULL or 0.0

struct SOut {
int x;
struct SIn {
int y;
SIn : y() {} // or this could be a virtual function...
} in;
}

...

SOut out = SOut(); // initializes y but not x.

out = SOut(); // clears y but not x...

So, since using either approach breaks if given certain circumstances
the question of which is more correct seems unclear. Since this is a
performance issue

Are you sure? Have you proven so with valid measurements?
the real question is which is the faster, memset(x,
0, sizeof(x)) or x = X()?
One of them. Either of them. Neither of them. THe language
says nothing about performance (other than the standard library
'big-O' specs).
Another question is if the above code should
be clearing the value of x...so long as SIn has no constructor or
virtual functions it works, but as soon as it does the default
constructor of SOut no longer clears x. What law in C++ governs this
behavior?
I'll let someone else look that up, and at the same time advise
against using memset in that context.

Is using memset immoral even if you KNOW that the object will never
have any virts? The only reason why I would think it might be is that
these structs have member functions...and calling memset on this
/seems/ icky.
IMO not just 'icky', but a dangerous practice.
I can definately see an argument comming over this and I
would like to be sure of my position...and IANAL.

Thanks.

I think a better question is why is there a need to 'zero-out' all
a class' data members in one sweep? IMO each data member has a specific
meaning and purpose, along with function(s) to manipulate it. If in the
course of processing, one or more data members need to be 'reset',
this should be done in that logic, unambiguously, e.g.

{
/* etc */
x.a = 0;
x.b = 0;
/* etc */
}

Many programmers think they can optimize code by hand better than
their compiler can. They're almost always wrong.

-Mike

[roberts.noah]

Mike Wahler wrote:

<ro**********@g mail.com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

I ran across some code that called memset(this, 0, sizeof(*this)) in
the member function of a structure in C++. This just looked wrong to
me so I did some web searching and it does indeed seem like a
questionable thing to do. Looking around further took me to a
newsgroup discussion that said the better approach was to do something
like sv = Struct(). The thing is that both cases seem to bo "ok" so
long as there are no virtual functions and no constructor in Struct or
any of its internals. Code like this does not initialize the object to
0:
And no pointer or floating point members. All-bits-zero is
not guaranteed to evaluate to NULL or 0.0

We are not concerned with the behavior of some obscure, non-existant
implementation in which NULL is not 0. In practice I have never seen
such a thing occur. As the compiler, hardware, OS, and all that is
known _I_ can guarantee that all bits zero is null and 0.0.

If I am to convince others that we need to change this practice I can't
make such arguments my sole point as for us and our targets they are
moot. Performance is given precidence over standards compliance here
so unless there is some *practical* reason the practice won't change.
If there is a piece of hardware out there that uses something other
than 0 to mean 0.0 or null then MAYBE, but afaik no such thing exists
and the x86 running Windows is certainly not one of them.

I agree that depending on an implementation is bad form, but I am
working in a Windows house and that is just plain the norm under such
situations. My OS, hardware, and compiler are not likely to change in
such a manner and nobody is concerned with compatibility with something
obscure or theoretical.

the real question is which is the faster, memset(x,
0, sizeof(x)) or x = X()?

One of them. Either of them. Neither of them. THe language
says nothing about performance (other than the standard library
'big-O' specs).

I was hoping for a practical answer.
I think a better question is why is there a need to 'zero-out' all
a class' data members in one sweep?

Note that I did specify structure and not class.

[red floyd]

ro**********@gm ail.com wrote:

Note that I did specify structure and not class.

So? The *ONLY* difference between a struct and a class is the default
access (struct => public, class => private).

A class can be a POD, a struct can be a non-POD. The key thing is that
while memset(this,0,s izeof(*this)) may be OK in certain circumstances on
a POD, using it leads to bad habits. And if it changes so that your
struct is no longer a POD, but has virtual functions, for example,
congrats! You just clobbered your VPTR.

Instead, you should create a constructor for your POD class

struct X {
int x;
int y;
X(int x_ = 0, int y_ = 0) : x(x_), y(y_) { }
};

[roberts.noah]

roberts.n...@gm ail.com wrote:

Is using memset immoral even if you KNOW that the object will never
have any virts? The only reason why I would think it might be is that
these structs have member functions...and calling memset on this
/seems/ icky. I can definately see an argument comming over this and I
would like to be sure of my position...and IANAL.

I can make my question clearer:

Assuming I have a Struct variable "s" that contains member functions,
which is the better way to clear its values and why?

1 - memset(&s, 0, sizeof(s));
2 - s = Struct();

If 1, is doing that from inside the structure really a big deal or is
it something that can be depended upon to work given that Struct will
never have virtual members?

[Andre Kostur]

ro**********@gm ail.com wrote in
news:11******** **************@ o13g2000cwo.goo glegroups.com:

Mike Wahler wrote:

<ro**********@g mail.com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

>I ran across some code that called memset(this, 0, sizeof(*this)) in
> the member function of a structure in C++. This just looked wrong
> to me so I did some web searching and it does indeed seem like a
> questionable thing to do. Looking around further took me to a
> newsgroup discussion that said the better approach was to do
> something like sv = Struct(). The thing is that both cases seem to
> bo "ok" so long as there are no virtual functions and no
> constructor in Struct or any of its internals. Code like this does
> not initialize the object to 0:
And no pointer or floating point members. All-bits-zero is
not guaranteed to evaluate to NULL or 0.0

We are not concerned with the behavior of some obscure, non-existant
implementation in which NULL is not 0. In practice I have never seen
such a thing occur. As the compiler, hardware, OS, and all that is
known _I_ can guarantee that all bits zero is null and 0.0.

However... you're posting in comp.lang.c++. We're platform agnostic over
here. All we get to assume is the Standard. How a particular
implementation behaves belongs in a newsgroup dedicated to that platform.
If I am to convince others that we need to change this practice I
can't make such arguments my sole point as for us and our targets they
are moot. Performance is given precidence over standards compliance
here so unless there is some *practical* reason the practice won't
change. If there is a piece of hardware out there that uses something
other than 0 to mean 0.0 or null then MAYBE, but afaik no such thing
exists and the x86 running Windows is certainly not one of them.
Nor should you. However, you are posting in comp.lang.c++ where we don't
get to assume platform-specific behaviours. And whatever we do say that
works, will work on _any_ platform (assuming the usual things, like a
Standards-compliant compiler... a well-formed program that doesn't
exhibit Undefined Behaviour, etc...).
I agree that depending on an implementation is bad form, but I am
working in a Windows house and that is just plain the norm under such
situations. My OS, hardware, and compiler are not likely to change in
such a manner and nobody is concerned with compatibility with
something obscure or theoretical.

That's nice... but doesn't belong in comp.lang.c++.

> the real question is which is the faster, memset(x,
> 0, sizeof(x)) or x = X()?

One of them. Either of them. Neither of them. THe language
says nothing about performance (other than the standard library
'big-O' specs).

I was hoping for a practical answer.

That would be platform-specific (and potentially implementation-
specific), and thus belongs in a newsgroup dedicated to your platform
and/or specific compiler.

[Cy Edmunds]

<ro**********@g mail.com> wrote in message
news:11******** **************@ g43g2000cwa.goo glegroups.com.. .

roberts.n...@gm ail.com wrote:

Is using memset immoral even if you KNOW that the object will never
have any virts? The only reason why I would think it might be is that
these structs have member functions...and calling memset on this
/seems/ icky. I can definately see an argument comming over this and I
would like to be sure of my position...and IANAL.

I can make my question clearer:

Assuming I have a Struct variable "s" that contains member functions,
which is the better way to clear its values and why?

1 - memset(&s, 0, sizeof(s));
2 - s = Struct();

If 1, is doing that from inside the structure really a big deal or is
it something that can be depended upon to work given that Struct will
never have virtual members?

In the current issue of C/C++ User's Journal, Koenig and Moo have an article
warning against violating abstractions. They also make the case that even
the simplest struct represents some level of abstraction unless it is
comprised of nothing but public data. I suggest you invest in a copy. (The
short form is that violating abstractions makes the code less maintainable
and less portable.)

--
Cy
http://home.rochester.rr.com/cyhome/

[Jim Langston]

<ro**********@g mail.com> wrote in message
news:11******** **************@ g14g2000cwa.goo glegroups.com.. .

I ran across some code that called memset(this, 0, sizeof(*this)) in
the member function of a structure in C++. This just looked wrong to
me so I did some web searching and it does indeed seem like a
questionable thing to do. Looking around further took me to a
newsgroup discussion that said the better approach was to do something
like sv = Struct(). The thing is that both cases seem to bo "ok" so
long as there are no virtual functions and no constructor in Struct or
any of its internals. Code like this does not initialize the object to
0:

All I can say was I was working on a program that was originally C. It did
the memset thing for it's structures and I didn't think much about it. I
made one of my own classes which initialized some data to certain values.
An existing structure was the best place to put this (which would then
really be a class but that's neither here nor there).

My code broke. Looking at my data I discovered that the variables I had
initialize in my class, which was inside the structure were 0, not the
values I initialized them to. So I had to get rid of the memset for this
structure, but it turned out that just about everything depended on the
variables being initialzed to 0.

So I then started making a constructor initializing the values to 0, and
soon discovered that this structure contained a lot more structures which
contained a lot more structures, etc... I wound up having to search out and
modify something like 15 structures and create constructors defaulting
values to zero just so I could put my class that needed to initialzied data
in the constructor inside this class.

It's not a good idea. Don't do it IMNSHO.

[Greg]

ro**********@gm ail.com wrote:

roberts.n...@gm ail.com wrote:

Is using memset immoral even if you KNOW that the object will never
have any virts? The only reason why I would think it might be is that
these structs have member functions...and calling memset on this
/seems/ icky. I can definately see an argument comming over this and I
would like to be sure of my position...and IANAL.

I can make my question clearer:

Assuming I have a Struct variable "s" that contains member functions,
which is the better way to clear its values and why?

1 - memset(&s, 0, sizeof(s));
2 - s = Struct();

If 1, is doing that from inside the structure really a big deal or is
it something that can be depended upon to work given that Struct will
never have virtual members?

Well it goes without saying that Struct will never have virtual methods
(that work) as long as there is code somewhere that is memsetting its
contents to 0. The problem with using memset in this way is that it
scatters such assumptions throughout the source code. In other words,
the definition of Struct does not express everything there is to know
about a Struct. Instead, the complete information can be found only by
examining every source file in the app, because the client has defined
the proper initialization state for a Struct.

In an object-oriented design, the object maintains its data, and
mediates both acccesses and changes to it. And the object itself
implements its initialization, not its clients. The benefits from doing
so are clear. Anyone wanting to find (or to change) how a Struct is
initialized, knows where to look for that code, and know also that it
is all in one place. The clients of Struct have a easier job as well. A
client no longer has to "know" that it's OK to call memset for a
Struct, but not, say, on a StructTwo. Such arbitrary knowledge does
nothing to produce better code, it simply makes it more difficult to
write correct code. And besides, how certain is it that Struct will be
a POD forever? How long does "never" usually last when it comes to
software design? Often not as long as one might expect - at least in my
experience.

Greg