invalid offsetof from non-POD type

[Gabriel Dos Reis]

John Quigley <johnw@lowestplane.org> writes:

| On Monday 21 April 2003 7:34 pm, Gabriel Dos Reis wrote:
| > John Quigley <johnw@lowestplane.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?
| >
| > -- Gaby
| 
| This isn't a precise definition, but I would expect that I can use offsetof to 
| compute the offset of a field of a non-POD type.  Then I can take a pointer 
| to an instance of that non-POD, advance it by adding the offset, and the new 
| pointer will be addressing the desired field in the instance.

That expectation is still not well formed:  the location of a
particular subobject depends on the complexity of the class hierarchy
and may require runtime computation (which means, you no longer have a
compile-time constant),  I'm leaving alone alignment issues.

| Perhaps whoever wrote the code in gcc has a real definition, since they seemed 
| to think that they were producing the right answer:

As I pointed out in the followup to Zack's message, what does it mean
to produce the "right" answer for a member whose type has a virtual
base class?  What is the "right" answer for member from a virtual base
class? 

Being able to describe a computational process is quite different from
knowing the outcome of that process at the description time.

If your point is that there are unaccuarate comments in the GCC source
code, then I agree with you.


Just FYI, the offsetof macro issue had had been  hashed in the past by
the C++ committee; from the archive, I can locate at least two major
debates, one in 1990, the second (the most "heated") in 1995.
Meanwhile, it has been debated to depth at committee meetings.  The
current wording is a result of consensus (from the opponents, I can
identify major library implementers). 

-- Gaby