Marco Spatz wrote:

class ClassA
{
public:
ClassA(void);
~ClassA(void);

protected:
void doA();
void doB();
};

class ClassB
{
friend void ClassA::doA();

public:
ClassB(void);
~ClassB(void);

protected:
void doWonderfulThings();
};

Both compiler (and the comeau online compiler) complain about the
'friend void ClassA::doA();' line for the same reason. They say, that
they cannot access the protected member doA() of ClassA.

Seems like a correct message to me.

This hasn't been a problem with the old compilers.

You're right. I tried the above code in g++ 3.2.3 and it compiled
without
problems. It's probably just a bug which was corrected in the newer
compilers.

But I think this is strange as ClassB isn't accessing doA() but does only
allow it to access all it's member functions (public, protected,private).

Not sure exactly what you mean here. In the above code, ClassA::doA()
isn't called, but it needs to be accessible for one to refer to it.
Otherwise,
the encapsulation would be broken. Since ClassA::doA() is protected,
ClassB can't see it, so it can't declare it as a friend.

I took a look at the standard but haven't found an answer. So I'm curious.
Is this code above legal?

I don't have a copy of the standard handy, but I don't believe the
above
code is legal.

Nate