invalid offsetof from non-POD type
Tue Apr 22 18:32:00 GMT 2003
On Tue, Apr 22, 2003 at 11:19:07AM -0700, Joe Buck wrote:
> On Tue, Apr 22, 2003 at 05:08:07AM +0200, Gabriel Dos Reis wrote:
> > Zack Weinberg <firstname.lastname@example.org> writes:
> > | Gabriel Dos Reis <email@example.com> writes:
> > |
> > | > John Quigley <firstname.lastname@example.org> writes:
> > | >
> > | > | While it is not standards compliant code, gcc still provides the correct
> > | > | result.
> > | >
> > | > The key issue is what do you define to be the "correct" result when you
> > | > apply offsetof() to a non-POD?
> > |
> > | I have never really understood why the C++ standard imposes this
> > | restriction. There would seem to be a well-defined answer to the
> > | question posed by offsetof(non-POD, data-member), since the data
> > | member does exist in memory at a well-defined offset from the
> > | beginning of the object. If that weren't true the compiler wouldn't
> > | be able to generate accesses to it.
> > That statement is confused.
> > The issue isn't that the compiler couldn't return some random number.
> > And no, the data do not always exist in memory, for example, a
> > subobject of "empty" class type" does not always occupy memory. Let
> > alone, subobject of morally virtual base classes. Which begs my
> > question.
> There are cases where offsetof() could not possibly return a meaningful
> value; in particular, for virtual base classes, the compiler must in
> general dereference one or more pointers to get to the field, so there
> is no fixed offset between the class object address and the field address
> (in GCC's implementation of a virtual base class, the derived class object
> must follow a pointer to get to the base class fields).
Is there an obvious reason why it would not be correct to do exactly
this? i.e. follow the virtual base pointers in order to establish the
result of offsetof?
[Is offsetof considered to be an integer constant expression? I have
no idea and I don't have the standard available.]
MontaVista Software Debian GNU/Linux Developer
More information about the Gcc-bugs