Interesting technique using templates to get around privacy

  • Thread starter Niklas Norrthon
  • Start date
N

Niklas Norrthon

I want to share a technique I recently have found to be useful
to get around some obstacles that data protection can raise.

Consider the following class:

// foo.h
#ifndef H_FOO
#define H_FOO

class Foo
{
private:
struct ImplementationDetails
{
int x;
int f() const;
} imp;

/* more data members */

public:
/* public interface */
Foo();
void mem_fun();
/* etc. */

/* friends */
friend void friend_fun(ImplementaionDetails&);
};

#endif

The function friend_fun is not a member of the class, but
can be considered as a part of the public interface. Typical
real life examples of this are operator<<(ostream&, const T&),
and operator+ (const T&, const T&) for a user defined type T.

A friend of a class has by definition access to that class's
private members, but it pass on the access rights to
other external functions. Usually this is not a problem, since
it can retrieve the data needed from the class, and pass along
that data. But when it comes to types it's a different matter.
Types are not values so they can't be passed as arguments in
the normal sence. Which means data that is of private declared
types can't be passed to any external functions.

For example:

// foo.cc (first try)
#include "foo.h"

namespace {
void helper(Foo::ImplementationDetails& i) /* problem */
{
/* do something */
i.f(); /* f is public, no problem */
}
}

void friend_fun(Foo::ImplementationDetails& imp)
{
helper(imp);
}

This does not work, because helper is not a friend of Foo. And
since helper is just a way to implement friend_fun, and not a public
function that should be called from anyone else it shouldn't be
made friend either.

One way to get around this is with a struct local to the friend
class, with static member functions:

// foo.cc (second try)
#include "foo.h"

void friend_fun(Foo::ImplementationDetails& imp)
{
struct Local
{
static void helper(Foo::ImplementationDetails& i) /* this works! */
{
/* do something */
i.f(); /* f is public, no problem */
}
};

Local::helper(imp);
}

There are two problems with this approach:
1. The implementation of Local::helper() must be inline, which makes
the code more difficult to follow (IMHO).

2. If helper common to two or more friends its code must be repeated
in every such function, which really is asking for trouble.

Now finally the solution is of course to use templates, as I have
already hinted in the subject line:

// foo.cc (third and final version */
#include "foo.h"

namespace {
template <typename Foo_ImpDet>
void helper(Foo_ImpDet& i)
{
/* do something */
i.f(); /* works for all types of i with a public f() member */
}
}

void friend_fun(Foo::ImplementationDetails& imp) /* unchanged from first try */
{
helper(imp);
}

I'm not asking any questions, just wanted to share. Comments are welcome.

/Niklas Norrthon
 
V

Victor Bazarov

Niklas said:
I want to share a technique I recently have found to be useful
to get around some obstacles that data protection can raise.

Consider the following class:

// foo.h
#ifndef H_FOO
#define H_FOO

class Foo
{
private:
struct ImplementationDetails
{
int x;
int f() const;
} imp;

/* more data members */

public:
/* public interface */
Foo();
void mem_fun();
/* etc. */

/* friends */
friend void friend_fun(ImplementaionDetails&);
};

#endif

The function friend_fun is not a member of the class, but
can be considered as a part of the public interface. Typical
real life examples of this are operator<<(ostream&, const T&),
and operator+ (const T&, const T&) for a user defined type T.

A friend of a class has by definition access to that class's
private members, but it pass on the access rights to
other external functions. Usually this is not a problem, since
it can retrieve the data needed from the class, and pass along
that data. But when it comes to types it's a different matter.
Types are not values so they can't be passed as arguments in
the normal sence. Which means data that is of private declared
types can't be passed to any external functions.

For example:

// foo.cc (first try)
#include "foo.h"

namespace {
void helper(Foo::ImplementationDetails& i) /* problem */
{
/* do something */
i.f(); /* f is public, no problem */
}
}

void friend_fun(Foo::ImplementationDetails& imp)
{
helper(imp);
}

This does not work, because helper is not a friend of Foo. And
since helper is just a way to implement friend_fun, and not a public
function that should be called from anyone else it shouldn't be
made friend either.

One way to get around this is with a struct local to the friend
class, with static member functions:

// foo.cc (second try)
#include "foo.h"

void friend_fun(Foo::ImplementationDetails& imp)
{
struct Local
{
static void helper(Foo::ImplementationDetails& i) /* this works! */
{
/* do something */
i.f(); /* f is public, no problem */
}
};

Local::helper(imp);
}

There are two problems with this approach:
1. The implementation of Local::helper() must be inline, which makes
the code more difficult to follow (IMHO).

2. If helper common to two or more friends its code must be repeated
in every such function, which really is asking for trouble.

Now finally the solution is of course to use templates, as I have
already hinted in the subject line:

// foo.cc (third and final version */
#include "foo.h"

namespace {
template <typename Foo_ImpDet>
void helper(Foo_ImpDet& i)
{
/* do something */
i.f(); /* works for all types of i with a public f() member */
}
}

void friend_fun(Foo::ImplementationDetails& imp) /* unchanged from first try */
{
helper(imp);
}

I'm not asking any questions, just wanted to share. Comments are welcome.

I have one question which, when you answer it, can lead to more questions,
of course.

Who and how uses 'friend_fun' function? To call it one would need to
expose 'imp' member, and that's already implicitly allowing access to
private parts of Foo. I would be surprised if you could do the same
thing if 'friend_fun' would have 'Foo' as its argument. Or maybe not.
Try changing it to

void friend_fun(Foo&);

and see what needs to be changed in your template technique (if anything
at all). I am just curious.

V
 
N

Niklas Norrthon

Victor Bazarov said:
Niklas Norrthon wrote:

I have one question which, when you answer it, can lead to more questions,
of course.

Who and how uses 'friend_fun' function? To call it one would need to
expose 'imp' member, and that's already implicitly allowing access to
private parts of Foo. I would be surprised if you could do the same
thing if 'friend_fun' would have 'Foo' as its argument. Or maybe not.
Try changing it to

void friend_fun(Foo&);

and see what needs to be changed in your template technique (if anything
at all). I am just curious.

You are right. I meant to have the friend_fun to take an argument of Foo&
and not Foo::ImplementationDetails&. I was typing too fast. The fourth
and (hopfully) final version of the above:

// foo.h
#ifndef H_FOO
#define H_FOO
class Foo
{
private:
struct ImplementationDetails {
int x;
int f() const;
} imp;
/* more data members */
public:
/* public interface */
Foo();
void mem_fun();
/* etc. */
/* friends */
friend void friend_fun(Foo&); };
#endif

// foo.cc (fourth and final version */
#include "foo.h"
namespace {
template <typename Foo_ImpDet>
void helper(Foo_ImpDet& i)
{
/* do something */
i.f(); /* works for all types of i with a public f() member */
}
}

void friend_fun(Foo& foo)
{
helper(foo.imp);
}

As I mentioned in my first post, a concrete example of when this technique
could be useful is a class for which operator<< is defined:

class Qwerty
{
public:
Qwerty();
virtual ~Qwerty() { }
/* etc */
friend std::eek:stream& operator<< (ostream&, const Qwerty&);

private:
typedef std::vector<std::string> Vec;
typedef Vec::const_iterator Iter;

Vec my_data;
};

template <typename Iter>
bool is_visible(Iter i)
{
/* complex logic to find out if *i should be printed or not */
return result_of_logic_above;
}

std::eek:stream& operator<< (ostream& os, const Qwerty& q)
{
for (Qwerty::Iter i = q.my_data.begin(); i != q.my_data.end(); ++i)
{
if (is_visible(i)) {
os << *i << ' ';
}
}
return os;
}

/Niklas Norrthon
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top