🚀 go-pugleaf

Phillip Knight wrote:

>         class ologstream : public ostream {
>            public:
	[ ... ]
>            ologstream& operator<< (foo &bar)
>                    { return *this; }  // do nothing
>         };

[ main() then attempts to use ologstream::operator<< on char*]

> on by ostream/ologstream operators.  The presence of an operator<<
> (overloaded or otherwise) in the dervided class consequently hides the base
> class operators which are public.  My question is; is this a bug in the
> language [...] ?


I believe this is the expected behavior for the language.
You can call the base class version with:

  out.ostream::operator<< ("Test one.");

Or (perhaps better depending on how "natural" you want the 
char * version to feel) give ologstream a member:

  ologstream& operator<< (char *str) 
      { ostream::operator(str); return *this; }

From the ARM (Section 13.1), or section 13.2.1 in Draft Standard:
"A function member of a derived class is *not* in the same scope 
as a function member of the same name in a base class."

The next page [ARM] gives a justification for this decision, the 
jist of which is that in a chain of derived classes, a "best match" 
may be found deep in the base class which will surprise programmers 
using the derived class.

Cheers,
Russell Johnston
<rjohnsto@edge.net>

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]