Re: invalid offsetof from non-POD type

[Matt Austern <austern at apple dot com>]

On Sunday, April 27, 2003, at 03:57 AM, Matthias Benkmann wrote:

> On Sat, 26 Apr 2003 11:44:59 +0100 Nathan Sidwell
> <nathan at codesourcery dot com> wrote:
>
> > Matthias Benkmann wrote:
> >
> > > Can't you wrap the POD-stuff in a real POD like this:
> > yes, but then you (well I've had to in the past), do something like
> >
> > class Foo {
> > 	public:
> > 	struct Pod { ...};
> > 	...
> > };
> >
> > class BiggerFoo : public Foo {
> > 	public
> > 	struct Pod : Foo::Pod { ... }; // this is a lie now
> > 	...
> > };
> >
> > It gets annoying to have to write
> > 	struct Pod { struct Foo::Pod base; ... };
> > as that exposes the hierachy to all BiggerFoo::Pod users.
>
> Doesn't inheritance always yield a non-POD? So this wouldn't even work
> with offsetof, would it?

I've got three claims about this discussion.

First, it's happening in the wrong place.  We don't want to be changing 
the language the g++ accepts from C++ to something else.  If C++98's 
restrictions on offsetof are too restrictive, then we should be having 
a discussion on the standards committee reflector to have those 
restrictions loosened in C++0x.  At present g++ is already pretty 
lenient: all we're doing  is issuing a warning.  We shouldn't be 
silencing that warning.  Users ought to be warned when they're doing 
something that's explicitly forbidden by the language standard.  I 
would strongly oppose any change to this in our compiler until we've 
brought up the issue with the standards committee.  We do not want 
half-specified language extensions.

Second, we should be careful about which restrictions we think are too 
loose and which are too tight.  The C++ standard gives implementers a 
lot of freedom about object layout, even if g++ doesn't use all of that 
freedom.  For example, imagine an implementation in which all base 
classes, not just virtual bases, are accessed through a pointer.  (For 
extra credit, imagine why an implementation like that might even be 
useful.)

Third, I do agree that POD is too restrictive a criterion.  It comes 
closer to what we want than other concepts we've already got in the 
language standard, which was probably why it was chosen: nobody wanted 
to come up with a new concept just for offsetof.  But that's just 
standardization technicality.  If we think it's worth the effort, I'm 
sure it's possible to define things more precisely.

			--Matt