🚀 go-pugleaf

This may or may not be appropriate for this group, but here goes:

Given this code snippet:
 
 	#include <strstream.h>
 	
        class foo {};
 
 	class ologstream : public ostream {
 	   public:
     	   ologstream() {}
    	   virtual ~ologstream() {};
                                  
 	   ologstream& operator<< (foo &bar)
                   { return *this; }  // do nothing
 	};
 
 
 	int main(int, char **)
 	{
 	   ologstream out;
 
 	   out << "Test one.";
           return 1;
       }
 
The program does not compile, giving an error where the char * is acted
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 or in the implementation, or is it just me?  I have attempted this
code fragment on several compilers with the same results, which makes me
wonder...  
This fragment, btw, is for illustration, not as an example of good coding 
or design.

Thanks for your time and consideration,
Phil Knight
psk3@pge.com
 
---
[ 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. ]

In article <01BAE8B0.C408A920@dino.int.com> Eugene Lazutkin
<eugene@int.com> writes:

|> > Well, a typical optimisation here would be to construct the temporary
|> > inside op+ directly into the return value slot. The construction of 'c'
|> > would likely pass the address of 'c' as the return value slot. Thus, with
|> > suitable inlining, it becomes very efficient.

|> > And the current wording of the draft allows such optimisations --
|> > effectively arbitrary copy constructor invocations can be eliminated if
|> > either the copy or the original is never used again (as in this example).

|> This is exactly the kind of optimization that one would be expecting but it cannot
|> possibly work, at least not with the non-inline copy constructors:

It can, because the standard says it can.  The standard explicitly
gives the implementation the right *not* to call the copy constructor
in certain well-defined cases.  This is one of them.  (Note that there
still must be an accessible copy constructor.)

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone


[ 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. ]

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. ]

Eugene Lazutkin wrote:
> > And the current wording of the draft allows such optimisations --
> > effectively arbitrary copy constructor invocations can be eliminated if
> > either the copy or the original is never used again (as in this example).
> 
> This is exactly the kind of optimization that one would be expecting but it cannot
> possibly work, at least not with the non-inline copy constructors:
> 
>         class   Complex
>         {
>                 Complex( const Complex& );
>         };
> 
>         int     stupid_global = 0;
>         Complex::Complex( const Complex& c ) : re( c.re ), im( c.im )
>         {
>                 stupid_global++;
>         }
> 
> compiler has no way to know that copy constructor has a non-local side effect.

	Completely irrelevent. The compiler is permitted to elide
the copy constructor anyhow. If this changes the observable behaviour
of you program it's your own fault that your code is not deterministic.
If you put a --stupid_global in the destructor, you can assume
after you're done it will be zero. But given a copy operation you 
can't assume it will be incremented by 1: it might be 2 or 0.
(0 is obviously not possible if the two variables are both used).

-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 web: http://www.maxtal.com.au/~skaller/
AUSTRALIA                      email: skaller@maxtal.com.au
---
[ 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. ]