Re: using offsetof with g++

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

Joe Buck <jbuck@synopsys.com> writes:

| On Thu, Nov 06, 2003 at 09:23:07PM +0100, Gabriel Dos Reis wrote:
| > | > I don't know where you put my favorite example that involve
| > | > references:
| 
| I wrote:
| > | Case 4 (it will do the wrong thing).
|  
| > Well, I can see reasons why it does not fit in that category.  The
| > compiler is computing the wrong answer not because the question does
| > not make sense, but just because the compiler has an erroneous
| > implementation of offsetof.  See the various PRs we have about it.
| 
| I was referring to the traditional implementation of offsetof.

That is what I guessed.  But the fact is that is is not usable  in C++
-- even if you restrict to PODs.  That is why we have PRs about it.

| >   Sure there is no requirement that a reference "exists" in A.  But as
| > a matter of fact, it does exists in form of a pointer in GCC
| > implementation.  And in nearly all cases, in other implementations, it
| > does exist in one form or the other.  The offset of that incanartion
| > is constant.
| 
| Yes, but that's at the implementation level.  But would traditional
| uses of offsetof work correctly if this case were implemented "correctly"?
| Maybe, maybe not.

C "traditional" implementations don't work in C++ even if we exempt
nearly-POD classes.  Basically, there is the issue of overloading
operator&, and even if you cast to char&, you get a non-constant
expression.  Basically, offsetof in C++ requires real support from the
compiler: It is far simpler just to provide an __offsetof__ operator to 
implement offset.  That is what other C++ compilers like EDG-based do.


|  If the code wants to write to a range of character
| starting from the address of the object, plus the offset, with a width
| determined by the size of the object, you've got another problem:
| sizeof(reference) returns the size of the referenced object.  Also,
| the user may expect the referenced object to be accessed, or s/he may
| expect the reference itself to be accessed.

sure, one gets all kind of issues. (that explains why my original
inclination is just to leave that as is.)  
Interestingly, is offsetof were expressed in terms of
pointer-to-members, the reference thingy would just be a hard
compile-time error.

| So, if you propose defining offsetof() for reference fields, you have
| the problem that you need to change the definition of sizeof().

Not, necessarily.  

-- Gaby