Re: [Libxmlplusplus-general] coding style issues



On Sat, Feb 01, 2003 at 05:19:00PM -0500, Stefan Seefeld wrote:

> >GCC 2.95 doesn't support using declarations at class scope if the name
> >is subsequently overloaded, so hidden functions must be redefined.
      ^^^^^^^^^^^^^^^^^^^^^^^
> >RedHat's GCC 2.96 does support such using decls, but FreeBSD's 2.95.4
> >doesn't, and AFAIK Debian's 2.95.4 doesn't either.
> >Should libxml++ work with GCC 2.95 ?
> 
> I'm puzzled, I just tried to compile this chunk with a home-built 2.95.3:
> 
> ----
> class A
> {
> protected:
>   void foobar();
> };
> 
> class B : public A
> {
> public:
>   using A::foobar;
    void foobar(int);   // overload, hides A::foobar
> };
> ----
> 
> with 'gcc version 2.95.3 20010315 (release)'
> 
> and it worked fine.

Yes, this is case (a) in the original mail, where a using decl changes
the access to a name. GCC 2.95 supports this. It doesn't support case (b),
where a using decl prevents name hiding. If you make the change above
(overload foobar in the derived class, which would hide A::foobar if the
using decl weren't present) and GCC 2.95 should fail with this error:

hiding3.cc:12: cannot adjust access to `void A::foobar()' in `class B'
hiding3.cc:11:   because of local method `void B::foobar(int)' with same name

Even the error message implies that in GCC 2.95 the only purpose of a
using decl is to change access, as in case (a), whereas the C++ standard
intends using decls to also prevent name-hiding, case (b).

If you now try to call A::foobar through an object of type B, like so:

int main()
{
  B b;
  b.foobar();
}

then you should get this error:

hiding3.cc: In function `int main()':
hiding3.cc:17: no matching function for call to `B::foobar ()'
hiding3.cc:11: candidates are: void B::foobar(int)

Therefore to prevent name-hiding you must modify B like so:

class B : public A
{
public:
  void foobar() { A::foobar(); }  // redefine, using A's implementation
  void foobar(int);
};

This only applies to case (b), where the name is overloaded in the
derived class. This fails for me with GCC 2.95.2, FreeBSD's (unofficial)
2.95.4 and Debian's (unofficial) 2.95.4, but works with RedHat's 2.96.
I can't check that it fails for the official 2.95.3, but I would be
surprised if it doesn't.

jon


-- 
"A scientific theory should be as simple as possible, but no simpler."
	- Albert Einstein




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]