This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: invalid offsetof from non-POD type

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 {
	struct Pod { ...};

class BiggerFoo : public Foo {
	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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]