Re: invalid offsetof from non-POD type

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

kaih at khms dot westfalen dot de (Kai Henningsen) writes:

| gdr at integrable-solutions dot net (Gabriel Dos Reis)  wrote on 22.04.03 in <m3u1cr6xgo dot fsf at uniton dot integrable-solutions dot net>:
| 
| > 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.
| 
| Not really. You might quibble over details, but I completely agree with  
| the basic content.

I'm not quibbling over the details: Actually the real semantics are in
the detail.  How do you handle multiple and virtual inheritance?

| > The issue isn't that the compiler couldn't return some random number.
| 
| Nobody is asking for some random number.

The question wasn't phrased in that term, but in effect, that is what
it boils down to.

| The number asked for is well- 
| defined for the cases in which one typically asks for it, as far as I can  
| see.

It remains to define "one typically asks for it".  Something I've been
asking for since the beginning, yet no answer :-(

-- Gaby