In article <1993Nov18.170507.3413@vedge.com> hendrik@vedge.com (Hendrik Boom) writes:
>: In article <CG74vK.B6y@stiatl.uucp> mdd@stiatl.uucp (Miles Duke) writes:
>: >rfg@netcom.com (Ronald F. Guilmette) writes:
>: >>If you could in fact use offsetof() to obtain the offset of private members,
>: >>that that would indeed violate the spirit of the ARM
>: >
>: >Would it violate the spirit of the ARM within the member functions of
>: >the object itself, where private member variables are in fact
>: >accessible?
>
>offsetof() for members inherited from virtual base clasees is likely to
>lead to trouble.

I think one could make the more general statetment that using C++ could
lead to trouble, but that's a separate issue. (1/2 :-)

With regard to offsetof() for (data) members inherited from virtual base
classes, I accept implicitly that Hendrik's assertion is probably true,
but I'd like to know *why* there should be any special problem in such
cases.  (Off the top of my head, I can't think of any obvious reason why
there should be.)

Hendrik?

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

: In article <CG74vK.B6y@stiatl.uucp> mdd@stiatl.uucp (Miles Duke) writes:
: >rfg@netcom.com (Ronald F. Guilmette) writes:
: >>If you could in fact use offsetof() to obtain the offset of private members,
: >>that that would indeed violate the spirit of the ARM
: >
: >Would it violate the spirit of the ARM within the member functions of
: >the object itself, where private member variables are in fact
: >accessible?

offsetof() for members inherited from virtual base clasees is likely to
lead to trouble.
:
: --
:
: -- Ronald F. Guilmette, Sunnyvale, California -------------------------------
: ------ domain address: rfg@netcom.com ---------------------------------------
: ------ uucp address: ...!uunet!netcom.com!rfg -------------------------------
--
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work: hendrik@vedge.com,  iros1!vedge!hendrik
at home: uunet!ozrout!topoi!hendrik

rfg@netcom.com (Ronald F. Guilmette) writes:

>In article <CFItC5.oGw@stiatl.uucp> mdd@stiatl.uucp (Miles Duke) writes:
>>Is it legal for an object class to make available the offsetof() one
>>of it's private data members as a way to permit other classes to
>>retrieve or set the value of these variables (as opposed to using
>>accessor methods)?

>Let me put it this way.  I know of no special rule prohibiting the use of
>the offsetof() macro to obtain the offset of private members.  But more
>generally, I think it is invalid to refer in any way to a member (any
>member) at any point where it is "inaccessible".

I would agree with that.  I have an application where an object would
like to supply the offset of some of its members to a trusted object
class that loads data into and out of ISAM files.  The offset of a member
is definitely accessible within the object's methods.  (At least on my
compiler :-)

>If you could in fact use offsetof() to obtain the offset of private members,
>that that would indeed violate the spirit of the ARM

Would it violate the spirit of the ARM within the member functions of
the object itself, where private member variables are in fact
accessible?

>(not to mention break-
>ing the hell out of encapsulation)

I don't know if it is much worse for encapsulation than the accessor
function that returns an lvalue (a reference to the private member),
instead of pair of accessor functions, one to get and one to set the
value of the member variable.  The main problem I am trying to solve
is finding a way to get a reference to the member within an arbitrary
instance of that object without using function pointers.  Pointers to
member variables (thanks to James Kanze, who was quite patient with
me), e.g. &C::privMemb worked, but they seemed to consider char[11] to
be a different "type" from char[21], and I have not found a way to
handle character arrays of arbitrary length using pointers to member
variables.

My goal was to implement an ISAM facility that, given a description of
the fields within a class, could receive requests to store the data
associated with object instances by marshalling data from the member
variables into the record format and then storing the record.  But I
wanted there to be one ISAM file for each distinct class that could
store or load itself, and hence only one description of the fields.
Many useful replies suggested how individual instances could describe
themselves, and some of these could work, even though it seems like it
means redescribing the record structure for each new instance of an
object instead of once per class.

Well, I wouldn't have asked the question if I didn't have some doubts,
so I appreciate all the responses I got.
--
Miles Duke                        ...!uupsi!stiatl!mdd
UNIX and Amiga Geek at Large      mdd@SalesTech.COM

In article <CG74vK.B6y@stiatl.uucp> mdd@stiatl.uucp (Miles Duke) writes:
>rfg@netcom.com (Ronald F. Guilmette) writes:
>>If you could in fact use offsetof() to obtain the offset of private members,
>>that that would indeed violate the spirit of the ARM
>
>Would it violate the spirit of the ARM within the member functions of
>the object itself, where private member variables are in fact
>accessible?

No.

>>(not to mention breaking the hell out of encapsulation)
>
>I don't know if it is much worse for encapsulation than the accessor
>function that returns an lvalue (a reference to the private member),

That is a different case entirely.  In that case, the author of a class
has intentionally made something which is (ostensibly) private accessible
outside of the class.

In the case of offsetof(), if that could be used to get the relative offsets
of private members, then the *client* of a class could do that without the
permission of the class author... thus violating the encapsulation which
the author had intended to implement.

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <CFItC5.oGw@stiatl.uucp> mdd@stiatl.uucp (Miles Duke) writes:
>Is it legal for an object class to make available the offsetof() one
>of it's private data members as a way to permit other classes to
>retrieve or set the value of these variables (as opposed to using
>accessor methods)?

Let me put it this way.  I know of no special rule prohibiting the use of
the offsetof() macro to obtain the offset of private members.  But more
generally, I think it is invalid to refer in any way to a member (any
member) at any point where it is "inaccessible".

It seems that at least some compilers agree with this view, any they issue
errors for attempts to use offsetof() to obtain the offset of an inaccessible
member.

>I suspect that using offsetof() has to work, since C++ is an extension
>of C...

I think it has to work.  Now the only question is "What does it have to
work on?"  I think it would be insane if it were required to work even
on members which are inaccessible (at the point where the offsetof()
"call" occurs).

>... and class members are analogous to structure elements.  But I
>wonder if this violates the spirit of C++, if not the letter of the
>ARM.

If you could in fact use offsetof() to obtain the offset of private members,
that that would indeed violate the spirit of the ARM (not to mention break-
ing the hell out of encapsulation) but like I say, many/most/all existing
compilers seem to prohibit references to private members... even when they
occur within offsetof() "calls".

(Follow-ups to comp.std.c++ please.)

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------