   C++:  ZeroMemory() and inheritance
  My practice is always to zero all data in a class object when I instantiate it: I do this by calling ZeroMemory(this,sizeof(class)).If I were to instantiate a derived class, I would want to do the same thing; however, ZeroMemory would be called twice for the derived class.  Though I do not see how it would harm the program, I feel like it is just sloppy.  If the base class were abstract, then that would not matter.  I am curious if there is some neater way around this; manually setting every data member would work but is impractical for large objects.   
Quote:My practice is always to zero all data in a class object when I instantiate it: I do this by calling ZeroMemory(this,sizeof(class)).Congratulations, you have a segfault!#include <string.h>class base {private:inti;public:base() {memset( this, 0, sizeof(*this) ); // Whoops, we've just shredded this instance's vptr table!}virtual ~base() {}virtual void foobar( int p ) {i = p * 2;}};class derived : public base {private:intj;public:derived() {memset( this, 0, sizeof(*this) ); // Whoops, we've just steam-rolled over this class's vptr table!j = 5;}void foobar( int p ) {j = j + p;}};int main() {base* b[] = { new base, new derived };b[0]->foobar( 3 ); // segfault! b[0]'s vptr table points to 0!b[1]->foobar( 3 ); // segfault! b[1]'s vptr table points to 0!delete b[0]; // segfault!  which destructor do we call?  we don't know because we don't have a vptr table!delete b[1]; // segfault!}Instead, do it the correct C++ way and use initializer lists:class base {private:inti;public:base() : i(0) { // <<-- use initializer lists!  // the ':' after the param-list and before the opening brace // signifies an initializer-list.  Here you can "construct"// your member variables to their default values}virtual ~base() {}virtual void foobar( int p ) {i = p * 2;}};class derived : public base {private:intj;public:derived() : j(5) {}void foobar( int p ) {j = j + 3;}};int main() {base* b[] = { new base, new derived };b[0]->foobar(); // Ok!b[1]->foobar(); // Ok!delete b[0];delete b[1];};  Using memcpy to copy objects is considered bad practice (see item 96 in "C++ Coding Standards" by Herb Sutter), and by extension, so is using memset/ZeroMemory in a constructor.First off, if your object has virtual functions, you've just overwritten the vtable pointer with the null pointer. Oops.Second of all, if you have member variables that are non-POD types, you've potentially clobbered any custom initialization that was done in their constructors.You should really use initializer lists to initialize an object via the constructor. If you feel your class is "too large" for this, then you probably have a bad design and you should split up the class into smaller pieces.   ;  Gah, better responses in 2 minutes.  I'm getting old and slow :)   ;  Typically when I see ZeroMemory its use is either wrong, redundant or sheer laziness. The impression I get from the code is that it's naive and/or plagiarised. Consequently I tend not to hold the programmer in all too high a regard. I'm probably not the only one who thinks this either I'm afraid. So, I'd suggest altogether stopping the ZeroMemory addiction [smile].   ;  Ah, well I see now what you mean about the vptr table.  That is not something I would have thought of.  I will take your suggestions in mind; I have used initializer lists in the past for constant data members.  I am programming a game and the objects for characters are quite large.   ;  ZeroMemory and Memset will also break any of the STL containers, as you'll be clobbering their pointer to dynamic memory. This means memory leaks, seg faults, and possibly weird behavior that could be quite difficult to determine the cause of. So any of your objects that happen to contain an STL container are going to run into the same problem.ZeroMemory was designed for the c language, and using it on c++ structures will cause problems if you're not very careful. Fortunately c++ provides methods (e.g. initialiser lists) that make ZeroMemory and Memset redundant in 99% of cases.   ;  Using ZeroMemory in a constructor isn't itself a problem:class Foo {    int x[10];    Foo() {   ZeroMemory(&x, sizeof(x));    }};Sure it's better to use std::fill, but nevertheless the above is not actually a problem.The tell-tale sign of the problem is basically:sizeof(*this)orZeroMemory(thisormemset(this;  To summarize: memset(), memcpy(), the non-portable ZeroMemory(), and friends, are only for what is called POD-type in C++ (Plain Old Data). Quote:9.4A 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. Similarly, 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.When still in doubt, then valid C++ code which is invalid C is not POD. When even after that in doubt, treat it as a non-POD.Personal rule of thumb: Do not assume that a type will always and ever remain a POD type (growing project, growing classes). Assume instead everything is non-POD. And only in the outermost and isolated nodes of your code, where there is some serious bottleneck, start thinking about PODs.   ;  It seems that everyone ( me included ) has had this grand mis-enlightenment at some point of their programming careers...