Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > polymorphism and protected help

Reply
Thread Tools

polymorphism and protected help

 
 
Dietmar Kuehl
Guest
Posts: n/a
 
      12-02-2004
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:rintf;
| // ...

(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 :rintf;
| // ...
| }

.... 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.
--
<(E-Mail Removed)> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

 
Reply With Quote
 
 
 
 
Matthias =?ISO-8859-1?Q?K=E4ppler?=
Guest
Posts: n/a
 
      12-02-2004
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:rintf;
> | // ...
>
> (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 :rintf;
> | // ...
> | }
>
> ... 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.
> --
> <(E-Mail Removed)> <http://www.dietmar-kuehl.de/>
> <http://www.contendix.com> - Software Development & Consulting


 
Reply With Quote
 
 
 
 
Dietmar Kuehl
Guest
Posts: n/a
 
      12-03-2004
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.
--
<(E-Mail Removed)> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[Help] c++ polymorphism and function overloading jungleman C++ 1 08-23-2010 03:26 PM
Help with Template-Template and Mixin Polymorphism TimeHorse C++ 0 08-09-2007 04:20 PM
Dynamic polymorphism vs. Static polymorphism Krivenok Dmitry C++ 13 06-01-2006 09:49 AM
I need help with "Inheritance" and "Polymorphism" Fao C++ 13 05-01-2006 11:55 PM
Difference between "Protected WithEvents myClassName" And "Protected myClassName" ? Andreas Klemt ASP .Net 2 07-05-2003 12:51 AM



Advertisments