"Carl Daniel" <cpdaniel@pacbell.net> wrote in message news:<M26I8.519$SJ1.96285825@newssvr13.news.prodigy.com>...
> "Joseph Heled" <joseph@itgssi.com> wrote in message
> news:3CF0859C.B9B4E44C@itgssi.com...
> >
> > It seems strange to me that having a private base class of type A would
>  prohibit
> > it's usage in derived classes. Am I wrong in thinking this C++ code should
> > compile cleanly? Anyone with another conforming compiler can comment?
> >
> > -Joseph
> >
> > ---------------------------------------
> > class A {
> > };
> >
> > class B : private A {
> > };
> >
> > class C : public B {
> > public:
> >   void f(A&) {}
>
> Make this   void f(::A&) {}
>
> > };
> > --------------------------------------
>
> The problem is that names are resolved before access is checked.  Since A is
> a base class of C, the mention of A in C::f resolves to the "A base of C".
> The access check then determines that since A is a private base, that this
> access is invalid.  Adding the :: scope qualifier forces the compiler to
> recognize A as the file-scope class, which is of course legal to use as a
> parameter to a member function in C.

I can't find standardese to support this. You can't "access a base class".
Private inheritance just means the members of A present in B are private
members of B and C. They can't be accessed by C::f. However, the base
A object of C is totally unrelated to the argument of C::f.

So, if we have
class A
{
  public: int i;
};
// class B and C as above
void C::f( A& a )
{
  a.i=42;
}
The access control check is done for a.i. Since i is a public member of
a (typeof(a)==A, A::i is public) there is no access problem.

Regards,
--
Michiel Salters

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Michiel Salters" <Michiel.Salters@cmg.nl> wrote in message
news:cefd6cde.0205280346.74c68f2c@posting.google.com...
> "Carl Daniel" <cpdaniel@pacbell.net> wrote in message news:<M26I8.519> >
The problem is that names are resolved before access is checked.  Since A is
> > a base class of C, the mention of A in C::f resolves to the "A base of
C".
> > The access check then determines that since A is a private base, that
this
> > access is invalid.  Adding the :: scope qualifier forces the compiler to
> > recognize A as the file-scope class, which is of course legal to use as
a
> > parameter to a member function in C.
>
> I can't find standardese to support this. You can't "access a base class".
> Private inheritance just means the members of A present in B are private
> members of B and C. They can't be accessed by C::f. However, the base
> A object of C is totally unrelated to the argument of C::f.

My statement was meant to reflect my speculation of what the compiler was
doing, and to propose a work-around.

I too don't find any standardese to support it, but both Comeau & GCC reject
the OP's code as-written.  Wouldn't be the first comonly reproduced compiler
bug though :)

-cd


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> I can't find standardese to support this. You can't "access a base class".
> Private inheritance just means the members of A present in B are private
> members of B and C. They can't be accessed by C::f. However, the base
> A object of C is totally unrelated to the argument of C::f.

I don't agree. The class-name is inserted in the declaration scope and in
scope of the class itself. The name A, during name lookup in the scope of C,
will be the class-name inserted in the base-class A. Due to the private
inheritance of A, it'll be inaccessable.

Bo-Staffan




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Joseph Heled" <joseph@itgssi.com> wrote in message
news:3CF0859C.B9B4E44C@itgssi.com...
>
> It seems strange to me that having a private base class of type A would
prohibit
> it's usage in derived classes. Am I wrong in thinking this C++ code should
> compile cleanly? Anyone with another conforming compiler can comment?
>
> -Joseph
>
> ---------------------------------------
> class A {
> };
>
> class B : private A {
> };
>
> class C : public B {
> public:
>   void f(A&) {}

Make this   void f(::A&) {}

> };
> --------------------------------------

The problem is that names are resolved before access is checked.  Since A is
a base class of C, the mention of A in C::f resolves to the "A base of C".
The access check then determines that since A is a private base, that this
access is invalid.  Adding the :: scope qualifier forces the compiler to
recognize A as the file-scope class, which is of course legal to use as a
parameter to a member function in C.

This raises two questions in my mind:
1. Is this simple case really what you were running into, or were you trying
to do something which would involve a conversion from C& (or C*) to A& (or
A*).  If so, such conversions are definitely invalid in the case of private
inheritance (that's what private inheritance is for, afterall).

2. I'm not sure this behavior is conforming (I haven't tried to figure it
out from the spec yet).  Comeau agrees with GCC though that the code as you
presented it is invalid.  IMO, if that code is ill-formed, it's a defect in
the spec since no conversion was attempted, and private inheritance is
specifically meant to make conversions to the base class invalid, not to
prevent access to independent instances of the base class.

-cd


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Carl Daniel" <cpdaniel@pacbell.net> wrote [abridged]...
> "Joseph Heled" <joseph@itgssi.com> wrote...
> > class A {
> > };
> >
> > class B : private A {
> > };
> >
> > class C : public B {
> > public:
> >   void f(A&) {}
>
> Make this   void f(::A&) {}
>
> > };
> > --------------------------------------
>
> The problem is that names are resolved before access is checked.
> Since A is a base class of C, the mention of A in C::f resolves to
> the "A base of C". The access check then determines that since
> A is a private base, that this access is invalid.  Adding the :: scope
> qualifier forces the compiler to recognize A as the file-scope class,
> which is of course legal to use as a parameter to a member function
> in C.

If that is the case, then surely the language is broken? There are only
two possible interpretations of A that make sense here:
1. the type called A
2. the (in this case, hidden) A subobject of a C object.
I fail to see how the example above -- or any other I can think of just
now -- can possibly be ambiguous in which it wants, given that there is
no "type" type in C++.

Regards,
Chris


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

It seems strange to me that having a private base class of type A would prohibit
it's usage in derived classes. Am I wrong in thinking this C++ code should
compile cleanly? Anyone with another conforming compiler can comment?

-Joseph

---------------------------------------
class A {
};

class B : private A {
};

class C : public B {
public:
  void f(A&) {}
};
--------------------------------------


> g++ -c t5.cc -Wall -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ./configure --enable-languages=c c++
Thread model: single
gcc version 3.1
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/cc1plus -v -D__GNUC__=3
-D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -D__gnu_linux__
-Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux
-Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_GNU_SOURCE -Acpu=i386
-Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__
t5.cc -D__GNUG__=3 -D__DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -quiet
-dumpbase t5.cc -Wall -version -o /tmp/ccmMtNyI.s
GNU CPP version 3.1 (cpplib) (i386 Linux/ELF)
GNU C++ version 3.1 (i686-pc-linux-gnu)
 compiled by GNU C version 3.0.4.
ignoring nonexistent directory "/usr/local/include/g++-v3/i686-pc-linux-gnu"
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include/g++-v3
 /usr/local/include/g++-v3/backward
 /usr/local/include
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/include
 /usr/include
End of search list.
t5.cc: In member function `void C::f(A&)':
t5.cc:2: `class A' is inaccessible
t5.cc:10: within this context

Compilation exited abnormally with code 1 at Sun May 26 18:31:31

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]