invalid offsetof from non-POD type

[Gabriel Dos Reis]

Nathan Sidwell <nathan@codesourcery.com> writes:

| Gabriel Dos Reis wrote:
| 
| > I'm not quibbling over the details: Actually the real semantics are in
| > the detail.  How do you handle multiple and virtual inheritance?
| The std already contains wording (wrt to base casting, IIRC), where you can
| do something via a non-virtual base path that you cannot do via a virtual
| base path. offsetof is the same.

That is an interesting point of view -- because it is -not- the way
offset currently works, or else you have a different wording in mind.  

Note that this new point of view has not been expressed when I
repeatedly asked for what constitutes the "right answer".  Using those
standard wordings implies that access control need to be applied. 

| 1) empty members and bases are not a problem. They have an address/offset,
| but you cannot touch the storage at that location.

And the original poster says he wanted to touch the storage of the
member.  

| 2) multiple non-virtual inheritance is no more a problem than in other data
| member access situations.

Then, one neeeds to spell out the constraints: Is member access
checked (presumably, yes since you proposed one takes standard
wordings)?  What about multiple or ambiguous members? 

| Like Zack, I think it strange that I can write &thing.member but not

The committee archive contains past debate on this issue.  See

  * c++std-lib-36
  * c++std-lib-56
  * thread starting at c++std-lib-4276 (read John Skaller's proposal)
  * thread starting at c++core-6935
  * thread starting at c++std-core-7310 (which mentions why offsetof
                doesn't play nicely with  members of reference types).


C++ semantics is not as simple as that of C.  In C++ &t is not always
the the address of t.


| offsetof(thing, member) (modulo virtual bases). I can even write
| '(char *)&thing.member - (char *)&thing', and all sane compilers will
| evaluate it at compile time.

I'm not sure "sane" is appropriate to conduct this technical discussion.
But... 

What a sane compile give you depends on what sane contructs you give
it. If you define the above to be your sane offsetof, why not just
wrap it into a macro or a template so that you're sure that your sane
offsetof always matches your definition of sane?

Point is "sane" is not an appropriate criterion for language
extension/design, because  what is "sane" depends on ones own
definition of "sane".

| It is interesting that John Quigley has a large body of real code
| that relies on the more lenient interpretation - if there's a lot of
| it out there, offsetof should be extended.

I'm not opposed in principle to extending offsetof.  What I'm
objecting to is the kind of description of semantics that have been
offered right now.

-- Gaby