🚀 go-pugleaf

Sergey Zhupanov <sergey@cis.ohio-state.edu> writes:

>Can derived functions overload each other instead of hiding
>or (worse yet) producing ambiguity?  Trivial examples are:
>
>Example 1:
>---------
>
>class A { public: void foo (int i); };
>class B : public A { public: void foo (char c); };
>
>Instead of overloading A::foo, B::foo hides it!

You can solve this problem with a `using' declaration.

	class B : public A { public: using A::foo; void foo (char c); };
	                             ^^^^^^^^^^^^^

Now the two definitions of `foo' will be overloaded.
See section 7.3.3 [namespace.udecl] of the draft standard,
which includes an example that is almost identical to the above.

>Example 2:
>---------
>
>class A { public: void foo (int i); }
>class B { public: void foo (char c); }
>class C : public A, public B {};

Again, you can use `using' declarations to solve the problem:

	class C : public A, public B {
	public:
		using A::foo;
		using B::foo;
	};

Of course, whether or not the compiler you are currently using
supports `using' declarations yet is another question... they
are a relatively new feature (introduced along with namespaces)
and many compilers don't yet support them.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3

---
[ 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 021F9BA0@slip6-2.acs.ohio-state.edu, Sergey Zhupanov <sergey@cis.ohio-state.edu> writes:
>Folks,
>
>Can derived functions overload each other instead of hiding
>or (worse yet) producing ambiguity?  

[ examples of functions in different classes in the hierarchy causing
  ambiguity instead of overloading ]

>This is the way the language is defined to behave.  Unfortunately, this 
>single "feature" prevents many interesting idioms from working.  (I can 
>elaborate if any one is interested.)
>
> ...
>
>Does any one know of a way to make the above code (modified in some way) 
>behave in the way intended, as opposed to "the C++ way?"

A using-directive will solve your problem without generating any extra code.

class B1 { public: int foo(int); };
class B2 { public: int foo(char); };
class D : public B1, public B2 {
public:
	using B1::foo; // "using" applies to a name, not to a signature
	using B2::foo;
	double foo(double); // new overload
};

Now all the overloaded "foo" functions in B1 and B2 are added to D's
scope, meaning they overload one another when called from a D object.

	D d;
	d.foo(1);   // calls B1::foo(int)
	d.foo('a'); // calls B2::foo(char)
	d.foo(1.0); // calls D::foo(double)

Notice how this differs from putting a forwarding function in D. There is no
overhead of any kind with a using-declaration.
---
Steve Clamage, stephen.clamage@eng.sun.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. ]

Steve Clamage (clamage@Eng.Sun.COM) wrote:

: In article 021F9BA0@slip6-2.acs.ohio-state.edu, Sergey Zhupanov <sergey@cis.ohio-state.edu> writes:
: >Folks,
: >
: >Can derived functions overload each other instead of hiding
: >or (worse yet) producing ambiguity?
  
[ eg. foo(char) hides foo(int) in a superclass ]
[ Steve responds ... ]

: A using-directive will solve your problem without generating any extra code.

: class B1 { public: int foo(int); };
: class B2 { public: int foo(char); };
: class D : public B1, public B2 {
: public:
: 	using B1::foo; // "using" applies to a name, not to a signature
: 	using B2::foo;
: 	double foo(double); // new overload
: };

[ snip ]

I have never understood why an overloaded member of a subclass hides a
superclass's member. It seems to be illogical and contradicts the
behaviour of non-class members. (It is also very irritating.)

What is 'using'? It does not seem to be standard.


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