This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: invalid offsetof from non-POD type
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.
> The issue isn't that the compiler couldn't return some random number.
Nobody is asking for some random number. The number asked for is well-
defined for the cases in which one typically asks for it, as far as I can
see.
MfG Kai