polymorphism and protected help

[xxx]

I'm having a little trouble understanding why a derivative class cannot
access a protected member of the base class in the following code:
#include <stdio.h>

class CBase
{
protected:
int x;
public:
CBase () {x = 123;}
public:
operator int () {return x;}
};

class CDerived : public CBase
{
public:
CDerived ()
{
CBase* p = this;
p->x = 456; // error: cannot access protected member
}
};

void main ()
{
printf ("CBase=%d\nCDe rived=%d\n", CBase (), CDerived ());
}
I don't see why CDerived shouldn't be able to access the integer "x" in
CBase without having CBase to declare CDerived as a friend. Can someone
explain to me why this is? Thank you.

[Dietmar Kuehl]

Matthias Käppler wrote:

Dietmar Kuehl wrote:

The above program will compile with several different C++ library
implementations - but not with a standard conforming one.
That doesn't really make sense.

It doesn't? Well, I think it really does: the replacement headers were
a nice idea which did not work out in practise. The reality is that
the C++ library implementer has no control over the ".h" versions but
is required to make sure that certain definitions from these headers
are made in namespace 'std'. The only available approach short of
keeping both versions in sync (which is not viable at all) is
something like this:

| // <cstdio>
| namespace std {
| #include "/usr/include/stdio.h"
| }

| // <stdio.h>
| #include <cstdio>
| using std::printf;
| // ...

(assuming the C version can be included from the file
/usr/include/stdio.h). However, this does not work because there are
loads of things defined in the standard C headers which are unknown
to either the C or the C++ standard and which other headers, e.g.
<unistd.h> rely upon being available in the global namespace.

The intention of putting away the declarations of the C library into
namespace 'std' was all noble - but it simply is not workable under
realistic conditions. Effectively, most implementations actually use
an approach like this:

| // <cfile>
| #include <stdio.h>
| namespace std {
| using ::printf;
| // ...
| }

.... and leave <stdio.h> unchanged (well, not really: it is still
necessary to add a few overloads to some of the headers e.g. for
const correctness but these declarations can easily be bolted on).
From what I know, the <cxyz> headers are the ISO-C++ counterparts to the classic xyz.h headers and were introduced in the standardization process to make clear which are C headers and which are not. It's actually highly encouraged to use them whenever you want to include C headers.
Yup, I know. Actually, I have spread this bad recommendation myself
in the past. At this time I was convinced that I can implement the C++
headers in a conforming way - and I can, as long as you don't want to
include any non-standard headers like <unistd.h>, too (well, actually,
<ctime> really gave me a headache when trying to encapsulate glibc's
<time.h> for some reason). Since the non-standard headers are
generally necessary in real live in some translation units, you can
only implement conforming C++ <c...> headers if you also have
control over the ".h" headers or at least their contents. I'm not
aware of any C++ library vendor who really has.
This is directly copied from <cstdio>:

//
// ISO C++ 14882: 27.8.2 C Library files
//

/** @file cstdio
* This is a Standard C++ Library file. You should @c #include this file * in your programs, rather than any of the "*.h" implementation files. *
* This is the C++ version of the Standard C Library header @c stdio.h, * and its contents are (mostly) the same as that header, but are all * contained in the namespace @c std.
*/

I know that not all C++ library implementations are able to tag
all C definitions into namespace 'std': that's an easy one for
someone who has implemented most of the standard C++ library and
whose implementation does not do it for practical reasons. I'm
sure that my implementation is not the only one. Actually, there
is an open issue concerning this exact stuff (see
<http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#456 >).

Although I recommended differently in the past, I recommend that
you use the ".h" version for the reasons given before.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[Matthias Käppler]

I wasn't aware of this problem. Thanks.

Dietmar Kuehl wrote:

Matthias Käppler wrote:

Dietmar Kuehl wrote:

> The above program will compile with several different C++ library
> implementations - but not with a standard conforming one.

That doesn't really make sense.

It doesn't? Well, I think it really does: the replacement headers were
a nice idea which did not work out in practise. The reality is that
the C++ library implementer has no control over the ".h" versions but
is required to make sure that certain definitions from these headers
are made in namespace 'std'. The only available approach short of
keeping both versions in sync (which is not viable at all) is
something like this:

| // <cstdio>
| namespace std {
| #include "/usr/include/stdio.h"
| }

| // <stdio.h>
| #include <cstdio>
| using std::printf;
| // ...

(assuming the C version can be included from the file
/usr/include/stdio.h). However, this does not work because there are
loads of things defined in the standard C headers which are unknown
to either the C or the C++ standard and which other headers, e.g.
<unistd.h> rely upon being available in the global namespace.

The intention of putting away the declarations of the C library into
namespace 'std' was all noble - but it simply is not workable under
realistic conditions. Effectively, most implementations actually use
an approach like this:

| // <cfile>
| #include <stdio.h>
| namespace std {
| using ::printf;
| // ...
| }

... and leave <stdio.h> unchanged (well, not really: it is still
necessary to add a few overloads to some of the headers e.g. for
const correctness but these declarations can easily be bolted on).

From what I know, the <cxyz> headers are the ISO-C++ counterparts to

the

classic xyz.h headers and were introduced in the standardization

process to

make clear which are C headers and which are not. It's actually

highly

encouraged to use them whenever you want to include C headers.

Yup, I know. Actually, I have spread this bad recommendation myself
in the past. At this time I was convinced that I can implement the C++
headers in a conforming way - and I can, as long as you don't want to
include any non-standard headers like <unistd.h>, too (well, actually,
<ctime> really gave me a headache when trying to encapsulate glibc's
<time.h> for some reason). Since the non-standard headers are
generally necessary in real live in some translation units, you can
only implement conforming C++ <c...> headers if you also have
control over the ".h" headers or at least their contents. I'm not
aware of any C++ library vendor who really has.

This is directly copied from <cstdio>:

//
// ISO C++ 14882: 27.8.2 C Library files
//

/** @file cstdio
* This is a Standard C++ Library file. You should @c #include this

file

* in your programs, rather than any of the "*.h" implementation

files.

*
* This is the C++ version of the Standard C Library header @c

stdio.h,

* and its contents are (mostly) the same as that header, but are

all

* contained in the namespace @c std.
*/

I know that not all C++ library implementations are able to tag
all C definitions into namespace 'std': that's an easy one for
someone who has implemented most of the standard C++ library and
whose implementation does not do it for practical reasons. I'm
sure that my implementation is not the only one. Actually, there
is an open issue concerning this exact stuff (see
<http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#456 >).

Although I recommended differently in the past, I recommend that
you use the ".h" version for the reasons given before.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[Dietmar Kuehl]

xxx wrote:

The intention was to have access to CBase's protected member from CDerived
without having to write a bunch of public accessors in CBase--it would
defeat the purpose to be protected.

A member function of a derived class has access to the protected members
of objects it knows to be derived. It does not have access to protected
members of sibling classes. I think this is a reasonable approach.
Otherwise, the protection would be rather thin: a could easily derive
from base and access protected members from static functions of his
derived class without ever even creating an object! This would be
practically useless. If you need to access base members of sibling
classes, you effectively need public access.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting