This is the mail archive of the gcc@gcc.gnu.org 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 Tue, Apr 22, 2003 at 05:08:07AM +0200, Gabriel Dos Reis wrote:
> Zack Weinberg <zack at codesourcery dot com> writes:
> 
> | Gabriel Dos Reis <gdr at integrable-solutions dot net> writes:
> | 
> | > John Quigley <johnw at lowestplane dot 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).

For empty fields, as Gaby mentions, there is also an issue, because the
object is not in fact stored in the struct/class at all (it has no fields,
and all its presence does is provide operations for the class as a whole),
however, the user is unlikely to care about this (there isn't a reason why
the user would want to use offsetof for an empty field).

However, I believe that the specification in the ISO standard is too
strict, and sometimes leads to inconveniences for the developer.
Frequently in mixed C/C++ systems, it is convenient to have data types
that are POD in every way except for the presence of a constructor, for
easier initialization.  Clearly for such types, offsetof can be
well-defined.  This means that the restrictions on offsetof() could be
relaxed.

Unfortunately, to do this right, some thought would have to go into a
specification of the extension.  And then there's the interaction of
offsetof issues with type-based aliasing, which is a whole new can of
worms.



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