Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #15109 > unrolled thread

litb is teh famous (private access specifier is private no more)

Back to article view | Back to comp.lang.c++

Contents

  litb is teh famous (private access specifier is private no more) Leigh Johnston <leigh@i42.co.uk> - 2012-03-30 18:53 +0100
    Re: litb is teh famous (private access specifier is private no more) Gareth Owen <gwowen@gmail.com> - 2012-03-31 08:37 +0100
    Re: litb is teh famous (private access specifier is private no more) jacob navia <jacob@spamsink.net> - 2012-03-31 10:47 +0200
      Re: litb is teh famous (private access specifier is private no more) gwowen <gwowen@gmail.com> - 2012-04-03 04:14 -0700
    Re: litb is teh famous (private access specifier is private no more) TJorgenson <tjorgenson@infinera.com> - 2012-03-30 21:29 -0700

#15109 — litb is teh famous (private access specifier is private no more)

Should the C++ standard be changed to stop litb's cool (and legal) hack 
to bypass private access specifier?  Bypassing private is very bad IMO.

<code>

template<typename Tag, typename Tag::type M>
struct Rob {
   friend typename Tag::type get(Tag) {
     return M;
   }
};

// use
struct A {
   A(int a):a(a) { }
private:
   int a;
};

// tag used to access A::a
struct A_f {
   typedef int A::*type;
   friend type get(A_f);
};

template struct Rob<A_f, &A::a>;

int main() {
   A a(42);
   std::cout << "proof: " << a.*get(A_f()) << std::endl;
}

</code>

<output>
proof: 42
</output>

http://bloglitb.blogspot.co.uk/2011/12/access-to-private-members-safer.html

/Leigh

[toc] | [next] | [standalone]

#15114

Leigh Johnston <leigh@i42.co.uk> writes:

> Should the C++ standard be changed to stop litb's cool (and legal)
> hack to bypass private access specifier?  Bypassing private is very
> bad IMO.

It's a very neat hack, but private doesn't mean secret.  There are
already ways to get at private and protected data members. litb's hack
appears to be a variant of Herb Sutter's Person #4
( http://www.gotw.ca/gotw/076.htm )
 
I'll quote Herb's summation, which answers the problem pretty
succinctly, and with which I agree:

  "This demonstrates an interesting interaction between two C++
   features: The access control model, and the template model. It turns
   out that member templates appear to implicitly "break encapsulation"
   in the sense that they effectively provide a portable way to bypass
   the class access control mechanism."

  "This isn't actually a problem. The issue here is of protecting
   against Murphy vs. protecting against Machiavelli... that is,
   protecting against accidental misuse (which the language does very
   well) vs. protecting against deliberate abuse (which is effectively
   impossible). In the end, if a programmer wants badly enough to
   subvert the system, he'll find a way, as demonstrated above in
   Examples 1 to 3."

  "The real answer to the issue is: Don't do that! Admittedly, even
   Scott Meyers has said publicly that there are times when it's
   tempting to have a quick way to bypass the access control mechanism
   temporarily, such as to produce better diagnostic output during
   debugging... but it's just not a habit you want to get into for
   production code, and it should appear on the list of "one-warning
   offences" in your development shop."

[toc] | [prev] | [next] | [standalone]

#15115

Le 30/03/12 19:53, Leigh Johnston a écrit :
[SNIP]

If you want really private structures just use C:

struct foo;
typedef struct foo *pFoo;

Now you can use struct foo and pFoo everywhere without knowing anything 
about it. You can't allocate a foo, just a pointer to it, and you can't 
have a local variable of that type. It is 100% hidden and since you 
haven't got any description of its internal fields there is NO WAY you 
can access them.

This is much stronger than C++ "private". It has some drawbacks too, the 
main  one is that you can't do some hack to actually use the protected 
fields :-)

jacob

[toc] | [prev] | [next] | [standalone]

#15198

On Mar 31, 9:47 am, jacob navia <ja...@spamsink.net> wrote:
> Le 30/03/12 19:53, Leigh Johnston a écrit :

> If you want really private structures just use C:
>
> struct foo;
> typedef struct foo *pFoo;

You can (of course) do this forward declaration technique in C++
too...

And indeed, if you want to keep the implementation secret, its the
only way to go (although, lets be honest, a sufficiently determined
attacker who can inspect the object files will probably be able to
subvert that too - *security is hard*).

[toc] | [prev] | [next] | [standalone]

#15171

On Mar 30, 10:53 am, Leigh Johnston <le...@i42.co.uk> wrote:
> Should the C++ standard be changed to stop litb's cool (and legal) hack
> to bypass private access specifier?  Bypassing private is very bad IMO.

In 99.99 out of a 100 cases I would agree, but I think you need to
consider what private is trying to protect.

I think we usually think of private as a mechanism for protecting
class implementers from class users. IMO, private also protects class
users from class implementers. We all know that if users of a class
could access the private parts then they would be dependent on them.
Users don't try to get around this protection mechanism since it makes
then vulnerable to those changes.

I also believe it is sometimes useful to provide a standard way for
getting around private for use by the class implementers themselves.
Serialization, which is mentioned in the article, may be a valid use
for this. I have used a similar technique for generated code that
access private parts of a class that users of the class are not
supposed to touch.

At the end of the day, you really can't protect yourself anyway. a
user can always modify your header.

And there's always this kludge...

#define private public
#define protected public
#include <yourProtectedHeader.h>

Of course, this breaks the ODR unless you also compile the class
sources with the same kludge, but I know of no compiler that actually
has a problem generating code for this even if you don't.

Tony

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web