In article <1993Jun30.175813.1292@rcmcon.com> rmartin@rcmcon.com (Robert Martin) writes:
>daniels@NeoSoft.com (Brad Daniels) writes:
>
>>class B;
>
>>class A {
>>    int i;
>>protected:
>>    void prot() { i=1; };
>>public:
>>    A() { i=0; }
>>    void f(B*);
>>};
>
>>class B: public A {
>>public:
>>    B() {}
>>};
>
>>void A::f(B *b) { b->prot(); }
>>=========
>> Is the above legal?
>
>It looks legal to me.  ARM 11.5 says that prot can be accessed by
>pointers or references to A or any class derived from A.  B is derived
>from A so b->prot() ought to work.

Are you referring to the text: "a friend or a member function of a derived
class can access a protected nonstatic member of its base classes only
through a pointer, reference to, or object of the derived class itself (or
any class derived from that class)"?  You are saying, then, that the
parenthetical remark about it being possible to access members of a
class's base class through pointers to any derived classes implies that
you can access your own members in the same way.  I guess that makes sense.
It's certainly a convoluted way of getting the point across, but then,
I suppose no one has ever accused a standards committee of stating anything
very clearly...

Thanks,
- Brad
--
Brad Daniels   |  "Let others praise ancient times.
daniels@neosoft.com  |   I am glad I was born in these."
I don't work for NeoSoft, and | - Ovid (43 B.C. - 17 A.D)
don't speak for my employer. |

In article <C9GG7B.8s5@sugar.NeoSoft.COM> daniels@NeoSoft.com (Brad Daniels) writes:
>In article <1993Jun30.175813.1292@rcmcon.com> rmartin@rcmcon.com (Robert Martin) writes:
>>
>>It looks legal to me.  ARM 11.5 says...
>
>Are you referring to the text: "a friend or a member function of a derived
>class can access a protected nonstatic member of its base classes only
>through a pointer, reference to, or object of the derived class itself (or
>any class derived from that class)"?  You are saying, then, that the
>parenthetical remark about it being possible to access members of a
>class's base class through pointers to any derived classes implies that
>you can access your own members in the same way.  I guess that makes sense.
>It's certainly a convoluted way of getting the point across, but then,
>I suppose no one has ever accused a standards committee of stating anything
>very clearly...

The ANSI X3J16 committee did not write the ARM.  The ARM was written by the
people listed on the cover of the ARM.

If you think the ARM is convoluted in spots, welcome to the club.

--

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

In article <rfgC9H6qv.D7D@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <C9GG7B.8s5@sugar.NeoSoft.COM> daniels@NeoSoft.com (Brad Daniels) writes:
>>In article <1993Jun30.175813.1292@rcmcon.com> rmartin@rcmcon.com (Robert Martin) writes:
>>>
>>>It looks legal to me.  ARM 11.5 says...
>>
...
>>It's certainly a convoluted way of getting the point across, but then,
>>I suppose no one has ever accused a standards committee of stating anything
>>very clearly...
>
>The ANSI X3J16 committee did not write the ARM.  The ARM was written by the
>people listed on the cover of the ARM.

Ah.  I was quoting from the X3J16 working document.  It sounds like section
11.5 was copied intact.

>If you think the ARM is convoluted in spots, welcome to the club.

I actually have no opinion on the ARM, because I haven't been able to
find a copy of the damn thing.  I have tried several bookstores and
computer stores, but no one has it.  In fact, BookStop, which has a
very good computer section, has about 50 or 60 different C++ titles in
stock, but the ARM isn't even in their computer catalog of things I could
special order.  I guess university bookstores are the next step, but they
all have terrible hours.  Sigh.  Is there much (if anything) that is in the
ARM but not in the X3J16 working document?

- Brad
--
Brad Daniels   |  "Let others praise ancient times.
daniels@neosoft.com  |   I am glad I was born in these."
I don't work for NeoSoft, and | - Ovid (43 B.C. - 17 A.D)
don't speak for my employer. |

In article <C9GG7B.8s5@sugar.NeoSoft.COM> daniels@NeoSoft.com (Brad Daniels) writes:
>In article <1993Jun30.175813.1292@rcmcon.com> rmartin@rcmcon.com (Robert Martin) writes:
>>daniels@NeoSoft.com (Brad Daniels) writes:
>>
>>>class B;
>>
>>>class A {
>>>    int i;
>>>protected:
>>>    void prot() { i=1; };
>>>public:
>>>    A() { i=0; }
>>>    void f(B*);
>>>};
>>
>>>class B: public A {
>>>public:
>>>    B() {}
>>>};
>>
>>>void A::f(B *b) { b->prot(); }
>>>=========
>>> Is the above legal?
>>
>>It looks legal to me.  ARM 11.5 says that prot can be accessed by
>>pointers or references to A or any class derived from A.  B is derived
>>from A so b->prot() ought to work.
>
>Are you referring to the text: "a friend or a member function of a derived
>class can access a protected nonstatic member of its base classes only
>through a pointer, reference to, or object of the derived class itself (or
>any class derived from that class)"?  You are saying, then, that the
>parenthetical remark about it being possible to access members of a
>class's base class through pointers to any derived classes implies that
>you can access your own members in the same way.  I guess that makes sense.
>It's certainly a convoluted way of getting the point across, but then,
>I suppose no one has ever accused a standards committee of stating anything
>very clearly...
>
>Thanks,
>- Brad

 No!!! If it seems convoluted you're probably reading it wrong! The
call to b->Prot() is not legal. The term "that class" in the parenthetical
expression can only refer to "derived class" in the sentence itself. If it
referred to "its base classes" it would have to be plural. What it says
in this context is that Prot() can be accessed through a pointer, reference to,
or object of class B and from a pointer, reference to, or object of any class
derived from B.
 -- Pete

In article <1993Jul1.172845.6932@borland.com> pete@borland.com (Pete Becker) writes:
>In article <C9GG7B.8s5@sugar.NeoSoft.COM> daniels@NeoSoft.com (Brad Daniels) writes:
>>In article <1993Jun30.175813.1292@rcmcon.com> rmartin@rcmcon.com (Robert Martin) writes:
>>>daniels@NeoSoft.com (Brad Daniels) writes:
[ Example moved below and expanded ]
>>>>=========
>>>> Is the above legal?
>>>
>>>It looks legal to me.  ARM 11.5 says that prot can be accessed by
>>>pointers or references to A or any class derived from A.  B is derived
>>>from A so b->prot() ought to work.
>>
>>Are you referring to the text: "a friend or a member function of a derived
>>class can access a protected nonstatic member of its base classes only
>>through a pointer, reference to, or object of the derived class itself (or
>>any class derived from that class)"?  You are saying, then, that the
>>parenthetical remark about it being possible to access members of a
>>class's base class through pointers to any derived classes implies that
>>you can access your own members in the same way.  I guess that makes sense.
>>It's certainly a convoluted way of getting the point across, but then,
>>I suppose no one has ever accused a standards committee of stating anything
>>very clearly...
> No!!! If it seems convoluted you're probably reading it wrong! The
>call to b->Prot() is not legal. The term "that class" in the parenthetical
>expression can only refer to "derived class" in the sentence itself. If it
>referred to "its base classes" it would have to be plural. What it says
>in this context is that Prot() can be accessed through a pointer, reference to,
>or object of class B and from a pointer, reference to, or object of any class
>derived from B.

Huh?  How can you say it's not convoluted?  I had to read what you wrote
twice to be sure you weren't just restating what had already been said...
Ayway, the text in question doesn't directly address my example at all.
Let's expand the example a bit:

class B;

class A {
    int i;
protected:
    void prot() { i=1; };
public:
    A() { i=0; }
    void f(B*);
};

class B: public A {
public:
    B() {}
    void g(C *);
};

class C : public B {
public:
    C() {}
};

void B::g(C *c) {
    prot(); // legal, accessing through this (which is a B *)
  // Standard says I can access protected base class members
  // through pointers to my own class.
    c->prot();  // Also legal, by the parenthetical remark.  I can
  // access protected members of my base class through pointers
  // to classes dervied from me.
}
void A::f(B *b) { b->prot(); } // legality implied by legality of above
o    // Since I can access members of my base
    // class through pointers to classes
    // derived from me, I should also be
    // able to access my own members.

Clearer now?  It's still pretty convoluted, though.

- Brad
--
Brad Daniels   |  "Let others praise ancient times.
daniels@neosoft.com  |   I am glad I was born in these."
I don't work for NeoSoft, and | - Ovid (43 B.C. - 17 A.D)
don't speak for my employer. |

In article <C9I3Gw.952@sugar.NeoSoft.COM> daniels@NeoSoft.com (Brad Daniels) writes:
>>>
>>>Are you referring to the text: "a friend or a member function of a derived
>>>class can access a protected nonstatic member of its base classes only
>>>through a pointer, reference to, or object of the derived class itself (or
>>>any class derived from that class)"?  You are saying, then, that the
>>>parenthetical remark about it being possible to access members of a
>>>class's base class through pointers to any derived classes implies that
>>>you can access your own members in the same way.  I guess that makes sense.
>>>It's certainly a convoluted way of getting the point across, but then,
>>>I suppose no one has ever accused a standards committee of stating anything
>>>very clearly...
>> No!!! If it seems convoluted you're probably reading it wrong! The
>>call to b->Prot() is not legal. The term "that class" in the parenthetical
>>expression can only refer to "derived class" in the sentence itself. If it
>>referred to "its base classes" it would have to be plural. What it says
>>in this context is that Prot() can be accessed through a pointer, reference to,
>>or object of class B and from a pointer, reference to, or object of any class
>>derived from B.
>
>Huh?  How can you say it's not convoluted?  I had to read what you wrote
>twice to be sure you weren't just restating what had already been said...

 If you read the text linearly everything is there in order, which is
why I said it's not convoluted. That's not the same as saying it's easy to
read...

>Ayway, the text in question doesn't directly address my example at all.
>Let's expand the example a bit:
>
>class B;
>
>class A {
>    int i;
>protected:
>    void prot() { i=1; };
>public:
>    A() { i=0; }
>    void f(B*);
>};
>
>class B: public A {
>public:
>    B() {}
>    void g(C *);
>};
>
>class C : public B {
>public:
>    C() {}
>};
>
>void B::g(C *c) {
>    prot(); // legal, accessing through this (which is a B *)
>  // Standard says I can access protected base class members
>  // through pointers to my own class.
>    c->prot();  // Also legal, by the parenthetical remark.  I can
>  // access protected members of my base class through pointers
>  // to classes dervied from me.
>}
>void A::f(B *b) { b->prot(); } // legality implied by legality of above
>o    // Since I can access members of my base
>    // class through pointers to classes
>    // derived from me, I should also be
>    // able to access my own members.
>

 Aha, I see. The confusion here lies in recognizing what the access
restrictions apply to. A::f(B *) is a member of A, so within the body of
that function the code can access any members of any classes that A is
permitted access to. Since A is not derived from B, nor is A a friend of B,
that means that the code in the body of this function can only access public
members of B.
 The talk about pointers, references, or objects relates to classes
derived from B. The easy case is this:

 class B
 {
 protected:
     void f();
 };

 class C : public B
 {
 public:
     void g() { f(); } //legal: 'this' is a pointer to D
 };

Things get more confusing when you explicitly pass around pointers to objects:

 class D : public B
 {
 public:
     void g() { f(); }   // still legal. 'this'
      // is a pointer to D
     void h( B *bptr ) { bptr->f(); } // illegal
     void i( D *bptr ) { dptr->f(); } // legal
 };

The point of all those words is to make the attempted access in D::h()
illegal. Members of D are only allowed to access protected members of B through
pointers to D or to classes derived from D. Members of D are not allowed to
access protected members of B through pointers to B.
 -- Pete

>>>>daniels@NeoSoft.com (Brad Daniels) writes:
>>>
>>>>class B;
>>>
>>>>class A {
>>>>    int i;
>>>>protected:
>>>>    void prot() { i=1; };
>>>>public:
>>>>    A() { i=0; }
>>>>    void f(B*);
>>>>};
>>>
>>>>class B: public A {
>>>>public:
>>>>    B() {}
>>>>};
>>>
>>>>void A::f(B *b) { b->prot(); }
>>>>=========
>>>> Is the above legal?

>rmartin@rcmcon.com (Robert Martin) writes:

>>>It looks legal to me.  ARM 11.5 says that prot can be accessed by
>>>pointers or references to A or any class derived from A.  B is derived
>>>from A so b->prot() ought to work.

> daniels@NeoSoft.com (Brad Daniels) writes:
>>Are you referring to the text: "a friend or a member function of a derived
>>class can access a protected nonstatic member of its base classes only
>>through a pointer, reference to, or object of the derived class itself (or
>>any class derived from that class)"?

pete@borland.com (Pete Becker) writes:

> No!!!  The call to b->Prot() is not legal. The term "that
>class" in the parenthetical expression can only refer to "derived
>class" in the sentence itself. If it referred to "its base classes"
>it would have to be plural. What it says in this context is that
>Prot() can be accessed through a pointer, reference to, or object of
>class B and from a pointer, reference to, or object of any class
>derived from B.

After reading your analysis, I have come to agree that b->Prot() is
not legal, but not for the reason you state in your last sentence.
'f' is a member function of A.  'Prot' is a protected member of A not
of a base class of A.  Thus the statement in the ARM: "a friend or a
member function of a derived class can access a protected nonstatic
member of its base classes..." does not apply to A::f and b->Prot
since Prot is not a "protected nonstatic member of [A's] base classes".
--
Robert Martin       | Design Consulting   | Training courses offered:
R.C.M. Consulting   | rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

|I actually have no opinion on the ARM, because I haven't been able to
|find a copy of the damn thing.  I have tried several bookstores and
|computer stores, but no one has it.  In fact, BookStop, which has a
|very good computer section, has about 50 or 60 different C++ titles in
|stock, but the ARM isn't even in their computer catalog of things I could
|special order.  I guess university bookstores are the next step, but they
|all have terrible hours.  Sigh.  Is there much (if anything) that is in the
|ARM but not in the X3J16 working document?

Strange that you cannot find it.  Below find publisher's address and
phone numbers, for those people who choose to order it direct.

The *Annotated* C++ Reference Manual consists of about 1/2 reference manual,
and 1/2 *annotations* which give examples, explain the authors' thinking,
give examples of implementation, etc.  The X3J16 document is only directly
based on the *unannotated* part of the ARM -- the annotations remain unique
to the ARM.  The committee then has no obligation to consider the annotation
parts in their deliberations, but such are pretty crucial towards understanding
where C++ is coming from, and why.  I doubt many committee members would
argue that they personally could get away with not having a copy of the ARM
themselves.

The Annotated C++ Reference Manual [aka "ARM"]
Margaret A. Ellis and Bjarne Stroustrup
ISBN 0-201-51459-1
Addison-Wesley Publishing Company, 1990
One Jacob Way, Reading Mass., 01867 USA
phone:  (617) 944-3700
 (800) 358-4566
fax: (800) 333-3328

The OTHER ANSI/ISO C++ base document [there are TWO base documents] is:

ANSI X3.159-1989 "Programming Language -- C"

[Note that ISO in Geneva and DIN in Germany also have essentially the
 identical document]

the document contains the address:

American National Standards Institute
1430 Broadway, New York, New York, 10018 USA

but I also have a magazine article listing:

American National Standards Institute
11 West 42nd St, New York, New York 10036 USA
phone: (212) 642-4900
fax: (212) 302-1286

The ANSI document is rumored to be quite expensive.

Another possible source for a copy of the ANSI document is:

Global Engineering Documents
phone: (714) 261-1455
fax: (714) 261-7892

>>>>>daniels@NeoSoft.com (Brad Daniels) writes:
>>>>
>>>>>class B;
>>>>
>>>>>class A {
>>>>>    int i;
>>>>>protected:
>>>>>    void prot() { i=1; };
>>>>>public:
>>>>>    A() { i=0; }
>>>>>    void f(B*);
>>>>>};
>>>>
>>>>>class B: public A {
>>>>>public:
>>>>>    B() {}
>>>>>};
>>>>
>>>>>void A::f(B *b) { b->prot(); }
>>>>>=========
>>>>> Is the above legal?
>
>>rmartin@rcmcon.com (Robert Martin) writes:
>
>>>>It looks legal to me.  ARM 11.5 says that prot can be accessed by
>>>>pointers or references to A or any class derived from A.  B is derived
>>>>from A so b->prot() ought to work.
>
>> daniels@NeoSoft.com (Brad Daniels) writes:
>>>Are you referring to the text: "a friend or a member function of a derived
>>>class can access a protected nonstatic member of its base classes only
>>>through a pointer, reference to, or object of the derived class itself (or
>>>any class derived from that class)"?
>
>pete@borland.com (Pete Becker) writes:
>
>> No!!!  The call to b->Prot() is not legal. The term "that
>>class" in the parenthetical expression can only refer to "derived
>>class" in the sentence itself. If it referred to "its base classes"
>>it would have to be plural. What it says in this context is that
>>Prot() can be accessed through a pointer, reference to, or object of
>>class B and from a pointer, reference to, or object of any class
>>derived from B.

>>rmartin@rcmcon.com (Robert Martin) writes:

>After reading your analysis, I have come to agree that b->Prot() is
>not legal, but not for the reason you state in your last sentence.
>'f' is a member function of A.  'Prot' is a protected member of A not
>of a base class of A.  Thus the statement in the ARM: "a friend or a
>member function of a derived class can access a protected nonstatic
>member of its base classes..." does not apply to A::f and b->Prot
>since Prot is not a "protected nonstatic member of [A's] base classes".

This fact is why I was saying it was a bit convoluted.  The specific
case is not covered, but since a class can access a base class's protected
members through a pointer to a class derived from itself, it is sensible
to assume that it should also be able to access its own members through
such a pointer.  That implication should probably be made explicit, however.

- Brad
--
Brad Daniels   |  "Let others praise ancient times.
daniels@neosoft.com  |   I am glad I was born in these."
I don't work for NeoSoft, and | - Ovid (43 B.C. - 17 A.D)
don't speak for my employer. |

I was porting some vendor code to DEC C++ on DEC OSF/1 AXP, and I came
across this situation:

=========
class B;

class A {
    int i;
protected:
    void prot() { i=1; };
public:
    A() { i=0; }
    void f(B*);
};

class B: public A {
public:
    B() {}
};

void A::f(B *b) { b->prot(); }
=========

Apparently, the above works on many platforms, but my compiler doesn't
like it.  It's an interesting case, because clearly, class A has access
to its own protected members, but in this case, the member is being accessed
through a pointer to class B, which also has that member protected because
of inheritance.  The question is, in that instance, is "prot" a protected
member of class B or of class A?  If it's a protected member of class A
(which seems to be how most compilers, esp. Cfront, treat it), the access
is legal.  If it's a protected member of class B (which is how DEC C++
treats it), the access is not legal.

Section 11.5 is as close as the working document comes to discussing this
case.  That section seems to imply that the intent is along the lines of
what DEC C++ does, but the situation is not entirely analogous.  There,
it shows that you can't access a protected member of a class you inherit
from through a pointer to the inherited base class.  This case is the
converse of that: the code tries to access a protected member of itself
through a derived class.

I worked around the problem by casting the pointer to be a pointer to
the base class, but the language issue remains.  Is the above legal?

- Brad
--
Brad Daniels   |  "Let others praise ancient times.
daniels@neosoft.com  |   I am glad to be born in these."
I don't work for NeoSoft, and | - Ovid (43 B.C. - 17 A.D)
don't speak for my employer. |

daniels@NeoSoft.com (Brad Daniels) writes:

>class B;

>class A {
>    int i;
>protected:
>    void prot() { i=1; };
>public:
>    A() { i=0; }
>    void f(B*);
>};

>class B: public A {
>public:
>    B() {}
>};

>void A::f(B *b) { b->prot(); }
>=========
> Is the above legal?

It looks legal to me.  ARM 11.5 says that prot can be accessed by
pointers or references to A or any class derived from A.  B is derived
from A so b->prot() ought to work.

--
Robert Martin       | Design Consulting   | Training courses offered:
R.C.M. Consulting   | rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++