invalid offsetof from non-POD type

[Matt Austern]

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

> On Sat, 26 Apr 2003 11:44:59 +0100 Nathan Sidwell
> <nathan@codesourcery.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