This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: using offsetof with g++


On Nov 6, 2003, at 11:47 AM, Gabriel Dos Reis wrote:

I'm sure Matt remembers that when having a dinner in Kona with Bjarne
and others, I brought this issue but could not give any convinving
arguments as answers to the following basic question

Why do you want to take the offsetof a non-POD?

(I know Matt gave at least two reasons but I can't recall; I just
remember mine was not convincing enough).

The basic question can be phrased as: Why do you want to use offsets instead of pointers to members? Here are three possible answers: 1. You want to have non-C++ code that manipulates C++ objects. You can pass the non-C++ code a void* and an integer offset, but you can't very well pass it a complicated structure like a pointer-to-member. 2. You want to do things that pointers-to-members don't support, like arithmetic on offsets to iterate through data members. 3. You have legacy code that takes offsets, that you wrote when you had a compiler that failed to enforce the offsetof restrictions. Now you've got a stricter compiler. You could rewrite your code in terms of pointers to member, but you don't want to.

I don't think #3 is very convincing---it's a case for a compiler switch
that relaxes restrictions, but it's not a case for changing the language
standard.  #2 may or may not be convincing; it might serve better as
a case for making pointers to members more powerful.  #1 strikes
me as the best argument, since there is real need for interoperability
between C++ and other languages.

I don't remember which of these reasons I used when I was talking
to you and Bjarne last week; I don't think I was very coherent that
night.

--Matt


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]