AllanW@my-dejanews.com wrote in message
<6s2951$lae$1@nnrp1.dejanews.com>...
>
>bazthief.cpp could also gain access to all of foo's data without
>bothering with bar:
>    #define class struct
>    #define private public
>    #define protected public
>    #include "foo.h"
>    void baz()
>    {
>        // Doesn't steal name bar, but has full access anyway.
>        // Friend? We don' need no stinkin' friends!
>    }


Tried this once but came upon several problems.
1) Some compilers store the access in the mangled name. In that case it will
simply not work. (Does this allow for overloading on access? ;^>)
2) There is no garantee that the object layout will remain the same when
changing the access of it's members. I haven't really observed this in
any compiler though.

If 2 doesn't hold but 1 does, there is another (but very error prone way) to
achieve the same result. Define a class that is exactly the same as the
original, but with all private and protected keywords replaced by public.
Now cast a pointer to the object you want access to to this new class.
Indeed, we don't need no stinking friends.

>One of the earliest and most consistent C++ philosophies is
>that C++ prevents mistakes, but not fraud. None of the above
>code can happen by accident.
>

Indeed. Sometimes a programmer's got to do what a programmer's got to do.
Hope you throw away the source after using it though. I use tricks like this
sometimes when I have to repair an OO-database and I need access to those
private parts because they are corrupted.

Greetz,
Martijn (see sig for real email address)

--
The "friend" keyword should have been "lover", it allows access to
private parts.
My email address is intentionally invalid against spam
reply to mlievaart at orion in nl



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote in message <6sepi5$svk$1@nnrp1.dejanews.com>...
>In article <6s5o06$ml1@news3.euro.net>,
>  "Martijn Lievaart" <nobody@orion.nl> wrote:
>>
>> AllanW@my-dejanews.com wrote in message
>> <6s2951$lae$1@nnrp1.dejanews.com>...
>> >
>> >bazthief.cpp could also gain access to all of foo's data without
>> >bothering with bar:
>> >    #define class struct
>> >    #define private public
>> >    #define protected public
>>
>> Tried this once but came upon several problems.
>> 1) Some compilers store the access in the mangled name. In that case it
will
>> simply not work. (Does this allow for overloading on access? ;^>)
>> 2) There is no garantee that the object layout will remain the same when
>> changing the access of it's members. I haven't really observed this in
>> any compiler though.
>
>This won't work on all platforms, but it will work on SOME platforms,
>and since the compiler isn't required to diagnose this, there is the
>possibility that ill-informed programmers will consider the technique
>to be a success.  Very few companies code-review every change in every

Well that programmer ought to be fired (or severely reprimanded if it was
out inexperience). As I said, if I use a trick like this, I throw the code
away afterwards (no proof left ;^>). See below why I sometimes have to use
it. besides, I had a code review and we concluded that at that time there
was no alternative. Should have asked this group.

(snip)

>
>I don't care to discuss refinements of the technique, because I
>don't condone it in the first place. If pressed, I could come up with
>a dozen alternatives, some almost as bad, some even worse.
>

Consider this (non-typical) case.
We use an OO database that works very close together with the compiler. This
effectively means that the class hierarchy is cast in stone. We could do a
schema evolution to change access to members, but if I only want to repair
one private pointer that is corrupt, schema evolution is a lot of work, and
even more errorprone than to revert to these dirty tricks. So in that case I
use a trick, repair the database and throw the source away so it wont be a
disaster waiting to happen.

>
>I suggest you consider alternatives; there will *ALWAYS* be some.
>If practical, modify the class rather than the client. Why was the
>data made private in the first place? If it really shouldn't be
>private, because clients have a legit need to read and/or modify
>it, then remove the private keyword -- permamently, in all code.
>(This can happen in shops that use classes for encapsulation but
>aren't strictly OO). OTOH, if it's truely OO or if it really
>should be private, then don't modify it from client code, not even
>from throw-away client code. If absolutely neccesary, you can create
>a throw-away client member function and deal with it that way!

Yes, the throw away member is much better. I should have thought of that
then :-<.

Martijn

--
My email address is intentionally invalid against spam
reply to mlievaart at orion in nl




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6s5o06$ml1@news3.euro.net>,
  "Martijn Lievaart" <nobody@orion.nl> wrote:
>
> AllanW@my-dejanews.com wrote in message
> <6s2951$lae$1@nnrp1.dejanews.com>...
> >
> >bazthief.cpp could also gain access to all of foo's data without
> >bothering with bar:
> >    #define class struct
> >    #define private public
> >    #define protected public
> >    #include "foo.h"
> >    void baz()
> >    {
> >        // Doesn't steal name bar, but has full access anyway.
> >        // Friend? We don' need no stinkin' friends!
> >    }
>
> Tried this once but came upon several problems.
> 1) Some compilers store the access in the mangled name. In that case it will
> simply not work. (Does this allow for overloading on access? ;^>)
> 2) There is no garantee that the object layout will remain the same when
> changing the access of it's members. I haven't really observed this in
> any compiler though.

This won't work on all platforms, but it will work on SOME platforms,
and since the compiler isn't required to diagnose this, there is the
possibility that ill-informed programmers will consider the technique
to be a success.  Very few companies code-review every change in every
line of code; it's easy for this to slip through the cracks until it
bites someone, hard.

> If 2 doesn't hold but 1 does, there is another (but very error prone way) to
> achieve the same result. Define a class that is exactly the same as the
> original, but with all private and protected keywords replaced by public.
> Now cast a pointer to the object you want access to to this new class.
> Indeed, we don't need no stinking friends.

I don't care to discuss refinements of the technique, because I
don't condone it in the first place. If pressed, I could come up with
a dozen alternatives, some almost as bad, some even worse.

> >One of the earliest and most consistent C++ philosophies is
> >that C++ prevents mistakes, but not fraud. None of the above
> >code can happen by accident.
>
> Indeed. Sometimes a programmer's got to do what a programmer's got to do.
> Hope you throw away the source after using it though. I use tricks like this
> sometimes when I have to repair an OO-database and I need access to those
> private parts because they are corrupted.

I suggest you consider alternatives; there will *ALWAYS* be some.
If practical, modify the class rather than the client. Why was the
data made private in the first place? If it really shouldn't be
private, because clients have a legit need to read and/or modify
it, then remove the private keyword -- permamently, in all code.
(This can happen in shops that use classes for encapsulation but
aren't strictly OO). OTOH, if it's truely OO or if it really
should be private, then don't modify it from client code, not even
from throw-away client code. If absolutely neccesary, you can create
a throw-away client member function and deal with it that way!

> The "friend" keyword should have been "lover", it allows access to
> private parts.

Yet another way to access private data without commiting fraud.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]