C++Talk.NET

Lloyd J Lewins · Guest

The proposed resolution to DR 45 inserts the following sentence after 11
class.access paragraph 1:

"1. A member of a class can also access all names as [sic] the class of
which it is a member."

I don't think that this is correctly constructed English. I see two
possibilities:

a) This is a typo, and the correct change is:

"1. A member of a class can also access all names of the class of which
it is a member."

b) The intent is something more like:

"1. A member of a nested class can also access all names accessible by
any other member of the class of which it is a member."

I would prefer to use the language proposed for 11.8:

"1, A nested class is a member and as such has the same access rights
as
any other member."

A second problem is with the text in 11.4 Friends paragraph 2:

"However, the declarations of members of classes nested within the
friend
class cannot access the names of private and protected members from the
class granting friendship."

I suspect (hope) that this is an oversight. The proposed change to 11.8
class.access.nest paragraph 1 would appear to have eliminated this
restriction by removing the following text:

"nor to classes or functions that have granted friendship to an
enclosing
class;"

However, at least one compiler (gcc 3.4.3) doesn't appear to take my view,
and continues with the restrictions on access by classes within a friend
class, while implementing the rest of DR 45.

In case it is needed, I will argue here for the removal of this
restriction.
My particular case involves a (mainly) opaque class, which has a companion
class providing for reading and writing the internals of the opaque class.
It is preferred to make the companion class a friend of the opaque class

thus allowing only the companion class to modify the internals. The
companion class for good reasons of its own contains nested internal
classes
which perform most of the actual work. The following is a skeleton:

class opaque
{
// internal implementation

public:
// public interface

friend class companion;
};

class companion
{
// internal implementation

// internal classes which do the real work
class handler1 { };

class handler2 { };

// public interface
};

As 11.4 is currently written, the nested classes must either be also
declared as friends of the opaque class -- or the companion class must
provide access functions to the opaque class which allow all the nested
class operations to actually be performed by the companion class. Either
approach is awkward. Declaring nested classes as friends ties the opaque
class to the implementation details of the companion class. Adding new
handler classes requires that they are also made friends of opaque.
Further,
in order for them to be friends, companion must make opaque a friend --
thus
unnecessarily exposing the internal implementation of companion. Finally,
companion's declaration must be visible to opaque -- causing problems with
mutually recursive include files. The following is an example of the
necessary additional code:

class companion
// must be declared before opaque to allow friend class
companion::handlerX;
{
// internal implementation

// internal classes which do the real work
class handler1 { };

class handler2 { };

// public interface

// Don't want to do this -- but necessary to allow friend class
companion::handlerX;
friend class opaque;
};

class opaque
{
// internal implementation

public:
// public interface

friend class companion;
// Undesirable coupling between opaque and the implementation of
companion.
friend class companion::handler1;
friend class companion::handler2;
};

The alternative of access functions in the outer companion class leads to
lots of extra code to write -- with IMHO no advantage in structure of
protection.

The proposed changes to DR 45 take the view that nested classes are first
class members -- having all the rights of any other member. I see no
reason
why this should be restricted in the case nested classes within friend
classes.

Lloyd J. Lewins
Fellow,
Raytheon Co.,
[email]llewins (AT) raytheon (DOT) com[/email]
+1 (310) 647-8832

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]