Generic Friendship Policies

[Erik]

private and protected members can only be accessed by deriving a class
or by giving friendship. The problem with friendship is that friend
statements are written inside the class. A FriendShip Policy solves the
problem.
There are different proposals how to solve the problem: The first idea
is to provide the class with a macro
---------------------------------------------------------------------
#define FRIENDS_OF_FOO class A; class B; class C

class foo
{
friends FRIENDS_OF_FOO;
private:
int pfoo;
};

The classes A,B and C can now access the private member pfoo;
-----------------------------------------------------------------------------------------------------------------------------
Because I don't like macros I was looking for an generic
implementation. My first attempt looks like that:

template <class T>
class foo
{
friends T;
private: int pfoo;
};

class A
{
foo<A> myFoo;
};

class B
{
foo<B> myFoo;
}

class D
{
A a;
B b;
}

The solution above has several disadvantage:
- The compiler generates a class for each different template parameter
- class A,B cannot share class foo. because there are different types
of foo.
- To provide the class foo with more template parameter seemed not to
be an adequat way
- This is not legal C++ (some compilers refuse that code)
-----------------------------------------------------------------------------------------------------------------------------
The attemped is to use TYPELSIST from the Loki Library (Reference:
Modern C++ Design by Andrei Alexandrescu) hopefully removes the
restriction on friendship.
The policy is provided with a macro and a Typlist as template parameter

//header of friendship.hpp
#include "Loki/TypeList.h"
#include "Loki/EmptyType.h"

#define MAKE_FRIENDS(x= x::Parm1 ; friend x::Parm2; friend x::Parm3;
..... friend x::Parm51

template <class TList=Loki::Emp tyType> class FriendShip
{
public:
typedef typename TList::ParmList ;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 0,
Loki::EmptyType >::Result Parm1;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 2,
Loki::EmptyType >::Result Parm2;
...
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 50,
Loki::EmptyType >::Result Parm51;
};

//end of header friendship.hpp
-----------------------------------------------------------------------------------------------------------------------------
How can the policy be used? First we have to modify class foo:

template <class Friends_Of_Foo>
class foo
{
friends MAKE_FRIENDS(Fr iends_Of_Foo);
private:
int pfoo;
};

See below how foo can be used:

typedef FriendShip<TYPE LIST_3(A,B,C)> friends_of_foo;

class A
{
foo<friends_of_ foo> Foo;
};

class B
{
foo<friends_of_ foo> Foo;
};

class D
{
A a;
B b;
};

Now the class foo is adaptable and can be generically used.
I used friendship policies to encapsulate functors in dll-Libraries.
I'm not sure, if this is legal C++ code. The compilers I used accept
this code.
-----------------------------------------------------------------------------------------------------------------------------

[Alf P. Steinbach]

* Erik:

#define FRIENDS_OF_FOO class A; class B; class C

class foo
{
friends FRIENDS_OF_FOO;
private:
int pfoo;
};
C++ has no keyword 'friends'.

I'm not sure, if this is legal C++ code. The compilers I used accept
this code.

It's not syntactically correct C++.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Erik]

Sorry, this was a spelling error. You have to write friend instead of
friends.
This is only an extract I summarised, not the original code.

[Alf P. Steinbach]

* Erik:

Sorry, this was a spelling error. You have to write friend instead of
friends.
This is only an extract I summarised, not the original code.

It won't work with 'friend' either; the syntax for a 'friend'
declaration doesn't support multiple classes in one declaration.

What does that tell you?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Erik]

Ok, you are right. I'm too sloppy. Maybe I should show the original
code for the template class.

// start of header
//-----------------------------------------------------------------------------------------------------------------------------------------------------------
#ifndef FriendShip_17_1 0_2004_HPP
#define FriendShip_17_1 0_2004_HPP

#include <maya/defines.hpp>
#include <loki/TypeList.h>
#include <loki/EmptyType.h>

/*------------------------------------------------------------------------------
@history
<TABLE>
\Author Date Vers. Comment
------------ -------- --------
--------------------------------------------
E. Grießmann 17.10.04 1.00 R01 created
</TABLE>
*-----------------------------------------------------------------------------*/

#define MAKE_FRIENDS(x) x::Parm1 ; friend x::Parm2 ; friend x::Parm3 ;
friend x::Parm4 ; friend x::Parm5 ; \
friend x::Parm6 ; friend x::Parm7 ; friend
x::Parm8 ; friend x::Parm9 ; friend x::Parm10; \
friend x::Parm11; friend x::Parm12; friend
x::Parm13; friend x::Parm14; friend x::Parm15; \
friend x::Parm16; friend x::Parm17; friend
x::Parm18; friend x::Parm19; friend x::Parm20; \
friend x::Parm21; friend x::Parm22; friend
x::Parm23; friend x::Parm24; friend x::Parm25; \
friend x::Parm26; friend x::Parm27; friend
x::Parm28; friend x::Parm29; friend x::Parm30; \
friend x::Parm31; friend x::Parm32; friend
x::Parm33; friend x::Parm34; friend x::Parm35; \
friend x::Parm36; friend x::Parm37; friend
x::Parm38; friend x::Parm39; friend x::Parm40; \
friend x::Parm41; friend x::Parm42; friend
x::Parm43; friend x::Parm44; friend x::Parm45; \
friend x::Parm46; friend x::Parm47; friend
x::Parm48; friend x::Parm49; friend x::Parm50; \
friend x::Parm51
BEGIN_OF_NAMESP ACE_MAYA

template <class TList> class FriendShip;

namespace friend_ship {
typedef maya::FriendShi p<TYPELIST_1(Lo ki::EmptyType)> none;
}

template <class T = Loki::EmptyType >
struct Append
{
typedef typename T SingleFriend;
};
template <class TList = friend_ship::no ne>
class FriendShip
{
public:
typedef typename TList ParmList;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 0,
Loki::EmptyType >::Result Parm1;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 1,
Loki::EmptyType >::Result Parm2;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 2,
Loki::EmptyType >::Result Parm3;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 3,
Loki::EmptyType >::Result Parm4;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 4 ,
Loki::EmptyType >::Result Parm5;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 5 ,
Loki::EmptyType >::Result Parm6 ;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 6 ,
Loki::EmptyType >::Result Parm7 ;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 7 ,
Loki::EmptyType >::Result Parm8 ;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 8 ,
Loki::EmptyType >::Result Parm9 ;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 9 ,
Loki::EmptyType >::Result Parm10;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 10,
Loki::EmptyType >::Result Parm11;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 11,
Loki::EmptyType >::Result Parm12;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 12,
Loki::EmptyType >::Result Parm13;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 13,
Loki::EmptyType >::Result Parm14;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 14,
Loki::EmptyType >::Result Parm15;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 15,
Loki::EmptyType >::Result Parm16;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 16,
Loki::EmptyType >::Result Parm17;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 17,
Loki::EmptyType >::Result Parm18;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 18,
Loki::EmptyType >::Result Parm19;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 19,
Loki::EmptyType >::Result Parm20;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 20,
Loki::EmptyType >::Result Parm21;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 21
,Loki::EmptyTyp e>::Result Parm22;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 22
,Loki::EmptyTyp e>::Result Parm23;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 23
,Loki::EmptyTyp e>::Result Parm24;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 24
,Loki::EmptyTyp e>::Result Parm25;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 25
,Loki::EmptyTyp e>::Result Parm26;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 26
,Loki::EmptyTyp e>::Result Parm27;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 27,
Loki::EmptyType >::Result Parm28;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 28,
Loki::EmptyType >::Result Parm29;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 29,
Loki::EmptyType >::Result Parm30;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 30,
Loki::EmptyType >::Result Parm31;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 31,
Loki::EmptyType >::Result Parm32;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 32,
Loki::EmptyType >::Result Parm33;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 33,
Loki::EmptyType >::Result Parm34;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 34,
Loki::EmptyType >::Result Parm35;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 35,
Loki::EmptyType >::Result Parm36;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 36,
Loki::EmptyType >::Result Parm37;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 37,
Loki::EmptyType >::Result Parm38;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 38,
Loki::EmptyType >::Result Parm39;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 39,
Loki::EmptyType >::Result Parm40;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 40,
Loki::EmptyType >::Result Parm41;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 41,
Loki::EmptyType >::Result Parm42;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 42
,Loki::EmptyTyp e>::Result Parm43;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 43
,Loki::EmptyTyp e>::Result Parm44;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 44
,Loki::EmptyTyp e>::Result Parm45;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 45
,Loki::EmptyTyp e>::Result Parm46;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 46
,Loki::EmptyTyp e>::Result Parm47;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 47
,Loki::EmptyTyp e>::Result Parm48;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 48,
Loki::EmptyType >::Result Parm49;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 49,
Loki::EmptyType >::Result Parm50;
typedef typename Loki::TL::TypeA tNonStrict<TLis t, 50,
Loki::EmptyType >::Result Parm51;
};
END_OF_NAMESPAC E_MAYA

#endif
// end of header
//-----------------------------------------------------------------------------------------------------------------------------------------------------------

[Peter Julian]

"Erik" <er************ *@fmc-ag.com> wrote in message
news:11******** **************@ g43g2000cwa.goo glegroups.com.. .

private and protected members can only be accessed by deriving a class
or by giving friendship. The problem with friendship is that friend
statements are written inside the class. A FriendShip Policy solves the
problem.

I disagree, private and protected members can be accessed by providing
accessors. The problem with friendship is that it usually, but not always,
depicts a misdesigned interface (except in the case of operators or tightly
coupled classes). I can understand the use of friend with a deeply complex
and intertwined inheritence hierarchy, like STL's iostream. What i can't
fathom is the ideology that friend solves all issues. In my humble opinion,
the best policy is to only use friend as a last resort.

[BigBrian]

>The problem with friendship is that it usually depicts a misdesigned interface...

This is your opinion, with which I disagree. Public accessors which
return a reference to private and protected members are not much better
than having public member data. With a friend you can specify exactly
which classes have access to the data, instead of giving access to
EVERYBODY, either through an accessor or the data itself.

[Erik]

To use friends or not is a design decission, not a question if I like
it or not.
My design decision was to grant friendship.
I used the friendship policy for a special purpose.
1. Performance: Access private members is faster than to use a get or
set method (accessors)
2. Composition: I want to use pointer of class members in a wrapper
class dedicated for the user of the library. If I have a public set or
get function, the library user can indirectly access the private class
members. This was not my intention. Access given
by friendship are implementation details. (I know that you can also use
private inheritance)
3. Usability: Public Inheritance result in wide interface (A class with
a lot of methods). Besides, public inheritance is only useful if you
have a is-relationship. I also considered
private inheritance, but this proposal also result in restrictions I
don't want to have.
4. I also have the posibility to make constructors private. Thus I can
prevent the library
user to create an instance of a class member.

What I want to have is a class like this.

class Person
{
private:
//....
public:
class CName * name;
class CAddress * address;
class CWork * work;
class CData * data;
class CAnamnesis * anamnesis;
......
};

instead of such a class which is more difficult to use, to reuse and to
maintain.

class Person
{
private:
//....
public:
const std::string & get_last_name() ;
void set_last_name(c onst std::string &);
const std::string & get_first_name( );
void set_first_name( const std::string &);
const std::string & get_maiden_name ();
void set_maiden_name (const std::string &);
const std::string & get_address_str eet();
void set_address_str eet(const std::string &);
......
};

My initial question was, if the template class I propose is leagal C++.
I know that
friendship has also disadvantages, which must be considered.