invalid offsetof from non-POD type

[Gabriel Dos Reis]

Daniel Jacobowitz <drow@mvista.com> writes:

[...]

| > 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?

We could do that if we introduce the notion of dynamic "offsetof" and
we don't always return an integral constant.
(I believe the necessary machinery is already in place in dynamic_cast<>)._

| [Is offsetof considered to be an integer constant expression?  I have
| no idea and I don't have the standard available.]

Yes, both C and C++ requires that the value of offsetof() be an
integral constant. 

In 1995, when John Skaller raised again the offsetof() issue, it made
a proposal to make it an operator, i.e. part of the core language -- I
believe that would have been a better approach the standard more of
less requires some magic to get a sensible definition of offsetof.

In C++, the needs for a powerful offsetof is mitigeted by the notion
of pointer to members.  If we could subtract two pointer to data members
(or complete that algebraic type, borrowing words from John Skaller)
then I believe we would not have to reinvent whell anew for making
offsetof play nicely witg non-PODs.

As I said, this is not a new topic.

-- Gaby