Re: using offsetof with g++

[Matt Austern <austern at apple dot com>]

On Nov 6, 2003, at 2:21 PM, Michael Matz wrote:

> For exactly the same reasons you want to apply offsetof() to a C
> struct.  Now you might ask further why someone would then want to make
> this a non-POD struct.  I gave also reasons for that.  That is, I can
> return with a question which has to be answered by people wanting to
> restrict offsetof():
>
>    Why not allow offsetof on a nearly-POD?

The real answer (and I know that this is the real answer because I asked
the people on the C++ committee who wrote this restriction): the C++
standard does not have a notion of "nearly-POD" types.  It would have
been possible to define such a notion if anyone had thought it was
important enough to be worth doing.  At the time, nobody did.  It's not
at all impossible.  On the other hand, it's also a fair amount of work
defining this notion in correct standardese, and, given that this work
would be solely for the sake of one macro, and, at that, a macro that
is widely believed to be there solely to support legacy C code, it 
didn't
seem like a good tradeoff.

If you can persuade the C++ committee that offsetof is important not
only for legacy C code but also for new C++ code, then there's a good
chance that this restriction will be loosened in a future version of the
language.  On the other hand, you can also expect to be asked why
you want to use offsetof instead of pointers-to-member.  (And if you can
show that there are things you can't do with pointers to members, you
might find that people will prefer to solve the problem by removing
whatever limitation pointers to members have.)

In the meantime, I think that our compiler does the right thing: warn
about invalid uses of offsetof, even ones that might happen to "work"
with our particular implementation, but allow users to silence the
warning if they want to.  I'd rather not get into the business of 
language
extension one corner case at a time.

			--Matt