Re: Problem with a friend declaration when migrating project
On 8/23/2012 6:39 AM, Uwe Kotyczka wrote:
I have two classes, class A and class Property. Class Property has
an assignment operator: const Property& operator=(const double
dValue);
Class A has a member variable of type Property. Only in one
specific function of class A, say A::DoSetProperty, I want
that the property can be changed. Therefore I declared the
assignment operator of class Property private and made
A::DoSetProperty a friend function of class Property.
That worked fine in Visual Studio 2003, however when migrating
to Visual Studio 2010 the compiler complains that it can't
see the friend declaration of A::DoSetProperty, because
A::DoSetProperty is protected in class A.
As a workaround I can either make A::DoSetProperty public
(which is not what I want to do) or declare the complete
class A as a friend of class Property (which I do not wish
to do either). Or I make the assignment operator public,
but then it can be called in any function of class A and
not only in A::DoSetProperty.
What would be the best solution? I would prefer a clear design
over a workaround.
You have a chicken and egg design problem. On one hand, your property
requires friendship to use its operator=. So, you solve it by making
the user of operator= (your 'A::DoSetProperty' function) a friend of
Property. On the other hand, access to 'A::DoSetProperty' is blocked as
well, so you need to give your Property some way to access it. You can
make Property a *derived class* of A, but that's not right, is it?
Declare class Property a friend of A. After all, in order to see A's
private (and protected) parts, Property has to be either a friend or a
relative. Another possibility is to get rid of the extra indirection
(the 'A::DoSetProperty' nonsense), leave only 'A::SetProperty' around
and let *that member* be a friend of Property. What's the reason to
have that 'DoSetProperty', anyway?
V
--
I do not respond to top-posted replies, please don't ask