clean C++ granular friend equivalent? (Answer: Attorney-Client Idiom)
The Attorney-Client idiom may be what you're looking for. The mechanics are not too different from your member proxy class solution, but this way is more idiomatic.
templated Attorney-Client Idiom for more many classes
In my opinion this pattern is more trouble than it's worth.
Instead, maybe you'd consider defining interfaces for each access role, then pass the object around by references to the appropriate interface type. This is likely to be far more readable and intuitive, although it still requires you to define and maintain interfaces for each role.
The interfaces and which member functions they expose should be chosen to suit the access roles. You do not necessarily need a separate interface for each function. If you think you do, I'd view that as a code smell and take it as a cue to reevaluate the design. This is true when using the Attorney-Client / PassKey pattern as well.
The only advantage the Attorney-Client / PassKey pattern has is that it doesn't require the member functions to be virtual. But it is very likely that the performance cost of virtual functions is not important to your application.
A disadvantage is that the Attorney-Client / PassKey pattern encourages you to design the "interfaces" based on specific users (as in specific classes that access the Secret). This creates coupling. It is better to think in terms of generic roles, which can be assigned as appropriate.
Can we increase the re-usability of this key-oriented access-protection pattern?
I like this idiom, and it has the potential to become much cleaner and more expressive.
In standard C++03, I think the following way is the easiest to use and most generic. (Not too much of an improvement, though. Mostly saves on repeating yourself.) Because template parameters cannot be friends, we have to use a macro to define passkey's:
// define passkey groups
#define EXPAND(pX) pX
#define PASSKEY_1(pKeyname, pFriend1) \
class EXPAND(pKeyname) \
{ \
private: \
friend EXPAND(pFriend1); \
EXPAND(pKeyname)() {} \
\
EXPAND(pKeyname)(const EXPAND(pKeyname)&); \
EXPAND(pKeyname)& operator=(const EXPAND(pKeyname)&); \
}
#define PASSKEY_2(pKeyname, pFriend1, pFriend2) \
class EXPAND(pKeyname) \
{ \
private: \
friend EXPAND(pFriend1); \
friend EXPAND(pFriend2); \
EXPAND(pKeyname)() {} \
\
EXPAND(pKeyname)(const EXPAND(pKeyname)&); \
EXPAND(pKeyname)& operator=(const EXPAND(pKeyname)&); \
}
// and so on to some N
//////////////////////////////////////////////////////////
// test!
//////////////////////////////////////////////////////////
struct bar;
struct baz;
struct qux;
void quux(int, double);
struct foo
{
PASSKEY_1(restricted1_key, struct bar);
PASSKEY_2(restricted2_key, struct bar, struct baz);
PASSKEY_1(restricted3_key, void quux(int, double));
void restricted1(restricted1_key) {}
void restricted2(restricted2_key) {}
void restricted3(restricted3_key) {}
} f;
struct bar
{
void run(void)
{
// passkey works
f.restricted1(foo::restricted1_key());
f.restricted2(foo::restricted2_key());
}
};
struct baz
{
void run(void)
{
// cannot create passkey
/* f.restricted1(foo::restricted1_key()); */
// passkey works
f.restricted2(foo::restricted2_key());
}
};
struct qux
{
void run(void)
{
// cannot create any required passkeys
/* f.restricted1(foo::restricted1_key()); */
/* f.restricted2(foo::restricted2_key()); */
}
};
void quux(int, double)
{
// passkey words
f.restricted3(foo::restricted3_key());
}
void corge(void)
{
// cannot use quux's passkey
/* f.restricted3(foo::restricted3_key()); */
}
int main(){}
This method has two drawbacks: 1) the caller has to know the specific passkey it needs to create. While a simple naming scheme (function_key) basically eliminates it, it could still be one abstraction cleaner (and easier). 2) While it's not very difficult to use the macro can be seen as a bit ugly, requiring a block of passkey-definitions. However, improvements to these drawbacks cannot be made in C++03.
In C++0x, the idiom can reach its simplest and most expressive form. This is due to both variadic templates and allowing template parameters to be friends. (Note that MSVC pre-2010 allows template friend specifiers as an extension; therefore one can simulate this solution):
// each class has its own unique key only it can create
// (it will try to get friendship by "showing" its passkey)
template <typename T>
class passkey
{
private:
friend T; // C++0x, MSVC allows as extension
passkey() {}
// noncopyable
passkey(const passkey&) = delete;
passkey& operator=(const passkey&) = delete;
};
// functions still require a macro. this
// is because a friend function requires
// the entire declaration, which is not
// just a type, but a name as well. we do
// this by creating a tag and specializing
// the passkey for it, friending the function
#define EXPAND(pX) pX
// we use variadic macro parameters to allow
// functions with commas, it all gets pasted
// back together again when we friend it
#define PASSKEY_FUNCTION(pTag, pFunc, ...) \
struct EXPAND(pTag); \
\
template <> \
class passkey<EXPAND(pTag)> \
{ \
private: \
friend pFunc __VA_ARGS__; \
passkey() {} \
\
passkey(const passkey&) = delete; \
passkey& operator=(const passkey&) = delete; \
}
// meta function determines if a type
// is contained in a parameter pack
template<typename T, typename... List>
struct is_contained : std::false_type {};
template<typename T, typename... List>
struct is_contained<T, T, List...> : std::true_type {};
template<typename T, typename Head, typename... List>
struct is_contained<T, Head, List...> : is_contained<T, List...> {};
// this class can only be created with allowed passkeys
template <typename... Keys>
class allow
{
public:
// check if passkey is allowed
template <typename Key>
allow(const passkey<Key>&)
{
static_assert(is_contained<Key, Keys>::value,
"Passkey is not allowed.");
}
private:
// noncopyable
allow(const allow&) = delete;
allow& operator=(const allow&) = delete;
};
//////////////////////////////////////////////////////////
// test!
//////////////////////////////////////////////////////////
struct bar;
struct baz;
struct qux;
void quux(int, double);
// make a passkey for quux function
PASSKEY_FUNCTION(quux_tag, void quux(int, double));
struct foo
{
void restricted1(allow<bar>) {}
void restricted2(allow<bar, baz>) {}
void restricted3(allow<quux_tag>) {}
} f;
struct bar
{
void run(void)
{
// passkey works
f.restricted1(passkey<bar>());
f.restricted2(passkey<bar>());
}
};
struct baz
{
void run(void)
{
// passkey does not work
/* f.restricted1(passkey<baz>()); */
// passkey works
f.restricted2(passkey<baz>());
}
};
struct qux
{
void run(void)
{
// own passkey does not work,
// cannot create any required passkeys
/* f.restricted1(passkey<qux>()); */
/* f.restricted2(passkey<qux>()); */
/* f.restricted1(passkey<bar>()); */
/* f.restricted2(passkey<baz>()); */
}
};
void quux(int, double)
{
// passkey words
f.restricted3(passkey<quux_tag>());
}
void corge(void)
{
// cannot use quux's passkey
/* f.restricted3(passkey<quux_tag>()); */
}
int main(){}
Note with just the boilerplate code, in most cases (all non-function cases!) nothing more ever needs to be specially defined. This code generically and simply implements the idiom for any combination of classes and functions.
The caller doesn't need to try to create or remember a passkey specific to the function. Rather, each class now has its own unique passkey and the function simply chooses which passkey's it will allow in the template parameters of the passkey parameter (no extra definitions required); this eliminates both drawbacks. The caller just creates its own passkey and calls with that, and doesn't need to worry about anything else.
Is this key-oriented access-protection pattern a known idiom?
Thanks to your other question it looks like this pattern is now known as the "passkey" pattern.
In C++11, it gets even cleaner, because instead of calling
b.protectedMethod(SomeKey());
you can just call:
b.protectedMethod({});
How to name this key-oriented access-protection pattern?
I like, in decreasing preference:
- passkey friend idiom
- passkey-door friend idiom
- pass-door friend idiom
- key-door friend idiom
- partial-friend idiom
- restricted-friend idiom
I moved away from the key-lock/key-keyhole naming scheme to the pass naming scheme, which grew on me.
Make a friend class have only special access to 1 function of another class?
If there is one (or few) members functions in class A, that want to use class B's private member functions, then you can declare those one/few functions as friend. E.g.
class B {
// ...
friend void A::mutateB( B * );
// ...
};
See http://en.wikipedia.org/wiki/Friend_function
Alternative to nested class
class B
{
friend class A;
private:
B(int x1, int y1, int x2, int y2);
...
}
How to fake visibility of class (not of functions) in C++?
One possible solution would be to shove Util into a namespace, and typedef it inside the B and C classes:
namespace util_namespace {
class Util{
public:
static void calculate(); //implementation in Util.cpp
};
};
class B {
typedef util_namespace::Util Util;
public:
void foo()
{
Util::calculate(); // Works
}
};
class C {
typedef util_namespace::Util Util;
public:
void foo()
{
Util::calculate(); // Works
}
};
class D {
public:
void foo()
{
Util::calculate(); // This will fail.
}
};
If the Util class is implemented in util.cpp, this would require wrapping it inside a namespace util_namespace { ... }. As far as B and C are concerned, their implementation can refer to a class named Util, and nobody would be the wiser. Without the enabling typedef, D will not find a class by that name.
Can two classes friend each other?
You can have mutual friendship:
class A {
friend class B;
};
class B {
friend class A;
};
Whether or not this makes sense depends entirely on the problem you are trying to solve. It definitely could make sense in certain circumstances.
The only example from my current project that utilizes mutual friendship is a container implementation: the container class is a friend of its iterator class and vice versa.
Related Topics
Using the Less Than Comparison Operator for Strings
Global Function Definition in Header File - How to Avoid Duplicated Symbol Linkage Error
When to Make a Type Non-Movable in C++11
How to Get a "Codesigned" Gdb on Osx
Popen Simultaneous Read and Write
Differencebetween the /Ox and /O2 Compiler Options
Why Is Copy Constructor Called Instead of Conversion Constructor
Why Are C++ Stl iOStreams Not "Exception Friendly"
Conflict Between Dynamic Linking Priority in Osx
C++ "Error: Passing 'Const Std::Map<Int, Std::Basic_String<Char> >' as 'This' Argument of ..."
Cyclic Dependency Between Header Files
Static Member Access in Constant Expressions
Compare Double to Zero Using Epsilon
Why Does a C/C++ Compiler Need Know the Size of an Array at Compile Time
Invalid Use of Incomplete Type
Will a "Variablename;" C++ Statement Be a No-Op at All Times