Moving private functions to opaque inner

[Öö Tiib]

What triggered me to post it was that I saw in comp.std.c++ a
strange "Proposal: Compilation-unit scoped private member functions"
that received some positive feedback, so may be there is some
market for idiom like that? Idiom (sorry, I do not have name):

// A.hpp
class A
{
public:
// public interface
int PublicGetter() const;
int PublicSetter(int param);
private:
// the place for private member functions,
// so (sometimes annoying) bloat is removed
class P;
// only virtuals constructors and operators here
// ... not relevant for example
// member data not moved, this isn't "pimpl"
int data;
};

// A.cpp
class A::P
{
public:
// private functions of A hidden parameter exposed,
// 7 chars of bloat per signature compare with:
// "int A::PrivateGetter() const"
static int PrivateGetter(A const&x)
{
// 2 chars of bloat per access
return x.data;
}

// same here
static int PrivateSetter(A&a,int param)
{
x.data += param;
return x.data;
}
};

int A::PublicGetter() const
{
// 9 chars of bloat per private call
return P::PrivateGetter(*this,param);
}

int A::PublicSetter(int param)
{
// same here
return P::PrivateSetter(*this,param);
}

No differences in efficiency.
Removes most private functions from header.
Makes private calls more visible in code.
Changes in implementation modify header less likely.
May be that ... I do not see something obvious?


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Daniel Krügler]

Am 01.03.2013 18:51, schrieb Öö Tiib:
> What triggered me to post it was that I saw in comp.std.c++ a
> strange "Proposal: Compilation-unit scoped private member functions"
> that received some positive feedback, so may be there is some
> market for idiom like that? Idiom (sorry, I do not have name):

<nod>, yes I have used something similar to this as well. This idiom is
also useful when you have the need that a tester needs to have access to
class internals without exposing the test framework in the class
declaration. My own variation of this idiom is to replace the nested
class by a friend declaration, but the effects are similar.

namespace n {

// A.hpp
class A
{
public:
// public interface
int PublicGetter() const;
int PublicSetter(int param);
private:

friend class P;
int data;
};
}

Greetings from Bremen,

Daniel Krügler

[Andy Champ]

On 01/03/2013 17:51, �� Tiib wrote:
> May be that ... I do not see something obvious?

Your class A::P only has static function members, and no data - so it
has zero size, and n vtable. How does the consumer of class A know
this, so it knows what size new to perform?

Andy

[red floyd]

On 3/1/2013 9:37 PM, Andy Champ wrote:

> On 01/03/2013 17:51, 嘱 Tiib wrote:
>> May be that ... I do not see something obvious?
>
> Your class A::P only has static function members, and no data - so
> it has zero size, and n vtable. How does the consumer of class A
> know this, so it knows what size new to perform?

Irrelevant. There is no member variable of type A::P.

[Andy Champ]

On 02/03/2013 12:20, red floyd wrote:
> On 3/1/2013 9:37 PM, Andy Champ wrote:
>> On 01/03/2013 17:51, 嘱 Tiib wrote:
>>> May be that ... I do not see something obvious?
>>
>> Your class A::P only has static function members, and no data - so
>> it has zero size, and n vtable. How does the consumer of class A
>> know this, so it knows what size new to perform?
>
> Irrelevant. There is no member variable of type A::P.
>

<fx homer simpson> Doh!

In that case, what does the declaration of the class do that putting a
namespace instead of the class in the implementation file doesn't do?

Andy

[Cassio Neri]

> In that case, what does the declaration of the class do that putting a
> namespace instead of the class in the implementation file doesn't do?

Being a private member of A grants to P access to all members of A including A::data. In contrast, functions that are not members of either A or P (regardless the file or namespace they are in) cannot access A::data unless they are declared friends of A in "A.h" (but this would bring no benefit with respect to making such functions private members of A).

Thanks 嘱 Tib for the tip.

[Seungbeom Kim]

On 2013-03-02 14:47, Andy Champ wrote:
>
> In that case, what does the declaration of the class do that putting a
> namespace instead of the class in the implementation file doesn't do?

It makes the enclosed class (A::P) a member of the enclosing class (A),
allowing the former full access to the internals of the latter.

Otherwise, you can give a friendship instead of a membership,
as illustrated in Daniel Krügler's example.

--
Seungbeom Kim