"Greg Brewer" <nospam.greg@brewer.net> writes:

> I handle it with the following
>
> class B // or struct
> {
> public:
>    // define all data
> };
> class C : public B
> {
> public:
>    virtual void Nada(void) {}
>    C(void) {B *b = this; memset(b, 0, sizeof(B))}
> };

Is this guaranteed to never overwrite C data if B contains non-static
members?

Note that it may overwrite C data for empty class B:

  class B {}; // empty

  class C: public B // may use empty base optimization
  {
    int i;
  public:
    C()
    {
      memset(b, 0, sizeof(B)); // may overwrite the first byte of i
    }
  };

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Michiel.Salters@cmg.nl (Michiel Salters) writes:

> "Izidor" <igor@NOobrazSPAM.net> wrote in message news:<a8n4fg$rd0$1@wanadoo.fr>...
> > One thing you can do to avoid problem if the struct/class contains a vtab
> > le is
> >  to surround the variables by two labels named for example start: and end
> > :
> > Then you just have to memset from start with a size of end-start.
> >
> > Izidor.
>
> One: Label addresses are a GCC extension. I don't know any other
> compiler which supports it.
>
> Two:  That might still bomb (virtual base); you cannot assume there is
> a POD-like part within a non-POD class.

But you can provide one yourself:

  class X
  {
  public:
    // whatever you want
  private:
    struct members_t
    {
      // your POD members
    } members;
    // possibly add some non-pod members which would make members_t
    // a non-POD if included there
  };

Now you can use memset on X::members (in those scopes where you have
access to it).

However, IMHO it would be a better idea to replace that memset by
assigning members_t() (which does zero-initialize the struct).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Izidor" <igor@NOobrazSPAM.net> wrote in message news:<a8n4fg$rd0$1@wanadoo.fr>...
> One thing you can do to avoid problem if the struct/class contains a vtab
> le is
>  to surround the variables by two labels named for example start: and end
> :
> Then you just have to memset from start with a size of end-start.
>
> Izidor.

One: Label addresses are a GCC extension. I don't know any other
compiler which supports it.

Two:  That might still bomb (virtual base); you cannot assume there is
a POD-like part within a non-POD class.

Regards,
--
Michiel Salters

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I handle it with the following

class B // or struct
{
public:
   // define all data
};
class C : public B
{
public:
   virtual void Nada(void) {}
   C(void) {B *b = this; memset(b, 0, sizeof(B))}
};

Greg

"Michiel Salters" <Michiel.Salters@cmg.nl> wrote in message
news:cefd6cde.0204040441.43f6818f@posting.google.com...
> Ron Natalie <ron@sensor.com> wrote in message
news:<3CAB879E.5507858A@sensor.com>...
> > Atul Pinge wrote:
>
> > > Also, if just have regular methods in structures or classes we
> > > can still meset the class with nulls without any problems
> > > (memset(&structure, 0, sizeof(strcuture));)  Can we assume this to be
> > > standard C++ behavior?
> >
> > It's bad C++ form.  You can get away with it on what C++ calls
> > POD classes (essentially classes that contain nothing you weren't
> > able to do in C).
>
> I think this doesn't restrict things enough, does it?
> Shouldn't it be " on POD classes which don't contain floating-point
> or pointer members "? All-zeroes can be a trap representation
> for those types.
>
> Of course, you could write
>
> C::C() {
>   C temp = { 0 }; *this = temp;
> }
>
> which will set all floats to 0.0 and all pointers to NULL pointers.
>
> Regards,
> --
> Michiel Salters
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Thanks a lot for all the replies.  I understand that the constructor
is used for all the initializations.  But the problem I was having was
we already had some C structures defined in our code and these
structures were used for reading and writing into a database.  We
already have code which memsets these structures.  Now somebody was
suggesting to add methods (not virtual) in these structures and I
thought that since we already had memset statments in the code to set
the structures and these things could be implementation dependant, we
could break something when we start using some other compilers or
platforms (which is very likely to happen in near future).  That's why
I started wondering if these things are part of C++ standard.  The
concensus seems like I can get away with adding some regular methods
but virtual methods could be a problem.  But these things could be
compiler dependent.  Am I right?  And I personally would still like to
avoid assuming anything about memory management.  That has always
proved to work better for me.

Anyway, thanks a lot for the replies again.

Atul

"Izidor" <igor@NOobrazSPAM.net> wrote in message news:<a8n4fg$rd0$1@wanadoo.fr>...
> One thing you can do to avoid problem if the struct/class contains a vtab
> le is
>  to surround the variables by two labels named for example start: and end
> :
> Then you just have to memset from start with a size of end-start.
>
> Izidor.
>
>
> "Dave" <nospam@nospam.com> a ?rit dans le message de news: uarjg8ertmf
> 02d@corp.supernews.com...
> > I've run into the same problem before myself.  Using memset to initiali
>  ze a
> > class will clobber vftp every time.  In the few cases where I needed to
>  use
> > memset (because of other design decisions) I make sure that I do not us
>  e
> > virrtual functions in the base class or any derived classes.  It was li
>  ke
> > trying to program with one hand tied behind my back!
> >
> > Anyway, the constructor is what member initialization is for.  It's goo
>  d
> > form to use the member initialization list, and it is basically
> > self-documenting.  Also, if you allocate any memory in your constructor
>  ,
> > you'll probably need a virtual destructor anyway, so you can't use mems
>  et
> > from the caller.
> >
> > Good luck.
> >
> > --
> > David Yasko
> > "The day after tomorrow is the third day of the rest of your life."
> >
> >
> > "Ron Natalie" <ron@sensor.com> wrote in message
> > news:3CACBFD6.CB24D2B2@sensor.com...
> > :
> > :
> > : Michiel Salters wrote:
> > :
> > : > I think this doesn't restrict things enough, does it?
> > : > Shouldn't it be " on POD classes which don't contain floating-point
> > : > or pointer members "? All-zeroes can be a trap representation
> > : > for those types.
> > : >
> > : I didn't say that zeros would be a useful value (not necessarily
> > : null pointer or the floating point zero representation), just that
> > : it wasn't going to clobber the vtable pointer or some internal
> > : feature of C++.
> > :
> > : Using memset on POD types really isn't anly more or less valid in
> > : C++ than it is in C when it comes to whehter scribbling zero bytes
> > : is what you really on your objects are the right values.
> > :
> > : ---
> > : [ comp.std.c++ is moderated.  To submit articles, try just posting wi
>  th ]
> > : [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu
>  ]
> > : [              --- Please see the FAQ before posting. ---
>  ]
> > : [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html
>  ]
> > :
> >
> >
> > ---
> > [ comp.std.c++ is moderated.  To submit articles, try just posting with
>  ]
> > [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu
>  ]
> > [              --- Please see the FAQ before posting. ---
>  ]
> > [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html
>  ]
> >
>
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Izidor wrote:
>
> One thing you can do to avoid problem if the struct/class contains a vtable is
>  to surround the variables by two labels named for example start: and end:
> Then you just have to memset from start with a size of end-start.

The C++ standard doesn't allow you to insert labels in a class
definition. The only things you can label are statements, and statements
aren't allowed in struct definitions, except as part of a member
function's definition.

Now, if "start" and "end" are the first and last non-static data members
of a POD struct, then
static_cast<char*>&end+sizeof(end)-static_cast<char*>&start would give
you a valid range for memset(). Perhaps that's what you mean when you
talk about labels?

However, if it's a POD struct, then sizeof(object) is equally good. And
since we're talking about avoiding damaging vtable pointers, we're
explicitly NOT talking about POD structs. An implementation is allowed
to insert a vtable pointer, or anything else it wishes, anywhere it
wants to in a non-POD struct. The two most common places are at the
beginning and at the end, and there's good reasons for that, but it's a
bad idea to build that assumption into your code.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello,

We are trying to solve one particular problem and the following
discussion came up.  And somebody is saying, in C++ classes and
structures, if we add a method,  it does not change the size of
(return value of sizeof() operator) the structure or a class.  But if
we add a virtual method then it adds vtable at the end of structure at
the end of class and that increases the size of the structure or a
class.  Also, if just have regular methods in structures or classes we
can still meset the class with nulls without any problems
(memset(&structure, 0, sizeof(strcuture));)  Can we assume this to be
standard C++ behavior?  Is this behavior standarad accross compilers
or platforms?

Thanks in advance for any replies.
Atul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Atul Pinge wrote:
>
> Hello,
>
> We are trying to solve one particular problem and the following
> discussion came up.  And somebody is saying, in C++ classes and
> structures, if we add a method,  it does not change the size of
> (return value of sizeof() operator) the structure or a class.  But if
> we add a virtual method then it adds vtable at the end of structure at
> the end of class and that increases the size of the structure or a
> class.

While the whole thing is implementation defined, adding the first virtual
method adds a pointer to the size of the class.  After you take that
penalty, additional virtual fucntions don't cost anything else (they
take an entry in a table that the pointer points to, but all instances
of the class share that)

> Also, if just have regular methods in structures or classes we
> can still meset the class with nulls without any problems
> (memset(&structure, 0, sizeof(strcuture));)  Can we assume this to be
> standard C++ behavior?

It's bad C++ form.  You can get away with it on what C++ calls
POD classes (essentially classes that contain nothing you weren't
able to do in C).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Ron Natalie <ron@sensor.com> wrote in message news:<3CAB879E.5507858A@sensor.com>...
> Atul Pinge wrote:

> > Also, if just have regular methods in structures or classes we
> > can still meset the class with nulls without any problems
> > (memset(&structure, 0, sizeof(strcuture));)  Can we assume this to be
> > standard C++ behavior?
>
> It's bad C++ form.  You can get away with it on what C++ calls
> POD classes (essentially classes that contain nothing you weren't
> able to do in C).

I think this doesn't restrict things enough, does it?
Shouldn't it be " on POD classes which don't contain floating-point
or pointer members "? All-zeroes can be a trap representation
for those types.

Of course, you could write

C::C() {
  C temp = { 0 }; *this = temp;
}

which will set all floats to 0.0 and all pointers to NULL pointers.

Regards,
--
Michiel Salters

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Michiel Salters wrote:

> I think this doesn't restrict things enough, does it?
> Shouldn't it be " on POD classes which don't contain floating-point
> or pointer members "? All-zeroes can be a trap representation
> for those types.
>
I didn't say that zeros would be a useful value (not necessarily
null pointer or the floating point zero representation), just that
it wasn't going to clobber the vtable pointer or some internal
feature of C++.

Using memset on POD types really isn't anly more or less valid in
C++ than it is in C when it comes to whehter scribbling zero bytes
is what you really on your objects are the right values.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I've run into the same problem before myself.  Using memset to initialize a
class will clobber vftp every time.  In the few cases where I needed to use
memset (because of other design decisions) I make sure that I do not use
virrtual functions in the base class or any derived classes.  It was like
trying to program with one hand tied behind my back!

Anyway, the constructor is what member initialization is for.  It's good
form to use the member initialization list, and it is basically
self-documenting.  Also, if you allocate any memory in your constructor,
you'll probably need a virtual destructor anyway, so you can't use memset
from the caller.

Good luck.

--
David Yasko
"The day after tomorrow is the third day of the rest of your life."


"Ron Natalie" <ron@sensor.com> wrote in message
news:3CACBFD6.CB24D2B2@sensor.com...
:
:
: Michiel Salters wrote:
:
: > I think this doesn't restrict things enough, does it?
: > Shouldn't it be " on POD classes which don't contain floating-point
: > or pointer members "? All-zeroes can be a trap representation
: > for those types.
: >
: I didn't say that zeros would be a useful value (not necessarily
: null pointer or the floating point zero representation), just that
: it wasn't going to clobber the vtable pointer or some internal
: feature of C++.
:
: Using memset on POD types really isn't anly more or less valid in
: C++ than it is in C when it comes to whehter scribbling zero bytes
: is what you really on your objects are the right values.
:
: ---
: [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
: [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
: [              --- Please see the FAQ before posting. ---               ]
: [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
:


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

One thing you can do to avoid problem if the struct/class contains a vtab=
le is
 to surround the variables by two labels named for example start: and end=
:
Then you just have to memset from start with a size of end-start.

Izidor.


"Dave" <nospam@nospam.com> a =E9crit dans le message de news: uarjg8ertmf=
02d@corp.supernews.com...
> I've run into the same problem before myself.  Using memset to initiali=
ze a
> class will clobber vftp every time.  In the few cases where I needed to=
 use
> memset (because of other design decisions) I make sure that I do not us=
e
> virrtual functions in the base class or any derived classes.  It was li=
ke
> trying to program with one hand tied behind my back!
>
> Anyway, the constructor is what member initialization is for.  It's goo=
d
> form to use the member initialization list, and it is basically
> self-documenting.  Also, if you allocate any memory in your constructor=
,
> you'll probably need a virtual destructor anyway, so you can't use mems=
et
> from the caller.
>
> Good luck.
>
> --
> David Yasko
> "The day after tomorrow is the third day of the rest of your life."
>
>
> "Ron Natalie" <ron@sensor.com> wrote in message
> news:3CACBFD6.CB24D2B2@sensor.com...
> :
> :
> : Michiel Salters wrote:
> :
> : > I think this doesn't restrict things enough, does it?
> : > Shouldn't it be " on POD classes which don't contain floating-point
> : > or pointer members "? All-zeroes can be a trap representation
> : > for those types.
> : >
> : I didn't say that zeros would be a useful value (not necessarily
> : null pointer or the floating point zero representation), just that
> : it wasn't going to clobber the vtable pointer or some internal
> : feature of C++.
> :
> : Using memset on POD types really isn't anly more or less valid in
> : C++ than it is in C when it comes to whehter scribbling zero bytes
> : is what you really on your objects are the right values.
> :
> : ---
> : [ comp.std.c++ is moderated.  To submit articles, try just posting wi=
th ]
> : [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu =
   ]
> : [              --- Please see the FAQ before posting. ---            =
   ]
> : [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                    =
   ]
> :
>
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with=
 ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu   =
 ]
> [              --- Please see the FAQ before posting. ---              =
 ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                      =
 ]
>


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]