Re: C++ Bug in member class overloading

[Nathan Sidwell <nathan at acm dot org>]

Alexandre Oliva wrote:
> 
> On Apr 22, 1999, <rch@larissa.sd.bi.ruhr-uni-bochum.de> wrote:
> 
> > class MAFullMat:            // Instance of MOPTerm<MAFullMat>
> >   public MOPTerm<MAFullMat>
> > {
> [snip]
> >   class MAFullMat::expand{  // expand the MOPArg<MAFullMat> within MAFullMat
> 
> You don't need (and must not use) the qualifier here.  `class expand'
> is what you mean.  MAFullMat::expand would only be valid after a
> nested class declaration such as `class expand;' within the body of
> MAFullMat.  But there're also some weird errors with the `yep' member
> function, that are fixed in development snapshots.
I agree that you don't need the extra qualifier, but I can't find why it *must
not* be given (I think that's a failing on my part though). 
-- here's the little test case I was just playing with,

struct A
{
  int A::fn();
  int A::m;

  class A::expand {
  public: int m;
  };
};

nathan@manao:155>ss-g++ -c rosta.C -pedantic
rosta.C:4: warning: extra qualification `A::' on member `fn' ignored
rosta.C:5: warning: extra qualification `A::' on member `m' ignored
rosta.C:6: `A' does not have a nested type named `expand'
rosta.C:6: confused by earlier errors, bailing out

both A::fn, and A::m are accepted as members of A, shouldn't we be just as nice
about expand?

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk