«

Peter Jansson wrote:

> John Fullman wrote:
>
>> It could, but it would be just as easy to remove that protection code
>> from any header file.
>> That would only work if the header files were somehow write protected.
>>
> I agree.
>
> I believe this to be of little importance since the "attacker"

You are confused about the purpose of data hiding.
Reaching around the interface cannot be considered an "attack"
on the class library or anything else
because it isn't possible for application programmers
to injure anyone but themselves by doing so.
Data hiding (private data members) are more like a "safety handrail"
that helps prevent application programmers for *accidently*
accessing private data members directly.
Abrogating this safety mechanism may be evidence of stupidity
but *not* malice.

> still has access to the headers
> so that person could easily change private into public anyway.

Encapsulation is: When you work on a jigsaw puzzle, the
puzzle starts as a pile-o-parts in a big plastic bag.
The bag is encapsulation. As long as nobody gets "frisky"
the bag will only have parts from this puzzle.

Data hiding is if the bag is opaque and you have to reach
in to get parts. This means you can't see if you are grabbing
an edge part or a corner part or a middle part, nor what
colour it is.

Implementation hiding is if the entire bag is behind a barrier,
and to get another part you have to ask your mom. So you
don't even see the bag, nor know how full the bag still is,
nor even that there *is* a bag. Could be a box or one of
those "bingo" machine air-popup things or your cat could
be behind there dragging over another part every time your
mom holds out a cat treat for it. But your mom told you she
will give you another part whenever you ask for one, until
there are no more.
Socks

Hehe... Totally agree, unless the writer of the library left security
holes in private members.
But, more often than not, you are right... that is just shooting
yourself in the foot.

"John Fullman" <> wrote in message
news: oups.com...
> Hehe... Totally agree, unless the writer of the library left security
> holes in private members.
> But, more often than not, you are right... that is just shooting
> yourself in the foot.
>

How about quoting what you're responding to? This isn't a chat room.

-Howard

Howard wrote:
> How about quoting what you're responding to? This isn't a chat room.
>
> -Howard

Good point... but up until 30 seconds ago, I didn't know how to quote
someone. They had to go hide it on me.

As for my previous post, I was replying to the post above mine. You can
also switch to a tree view to see which message I was replying to.

"John Fullman" <> writes:

> As for my previous post, I was replying to the post above mine.

In my newsreader, there is no post above yours. We're not all (ab)using a
web browser to access Usenet, you know.

> You can also switch to a tree view

How would you know if my news reader has a tree view or not, or whether my
computer has a large enough screen to support such a layout? How would you
know if the server I'm connected to has received the post you're replying
to, or if it still retains it?

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

>Data hiding (private data members) are more like a "safety handrail"
>that helps prevent application programmers for *accidently*
>accessing private data members directly.

Nonsense! The standard doesn't define accidents, only the correct
semantics of the c++ programming language. Why speculate on different
uses this language feature might or might not be put into? The
definition is pretty straightword, that's all there is to it. Why
complicate simple things?

Furthermore, abrogating this safety mechanism may invoke undefined
behaviour depending on how the mechanism was abrogated, and what's the
practical difference between stupidity and malice as far as the
correctness of the program is concerned? None, if the program invokes
undefined behaviour the only important question is how to fix it unless
interested in finding who to blame or other off-topic activities.

If the source is modified, well, then it reasonably follows that we are
not talking about the original source at that point and the question is
what the new one looks like. It might be a brilliant design change, not
evidence of stupidity or it might invoke undefined behaviour. The point
is that we don't know, why should anyone pretend that he/she does?

Sherm Pendley wrote:
> "John Fullman" <> writes:
>
> > As for my previous post, I was replying to the post above mine.
>
> In my newsreader, there is no post above yours. We're not all (ab)using a
> web browser to access Usenet, you know.
>
> > You can also switch to a tree view
>
> How would you know if my news reader has a tree view or not, or whether my
> computer has a large enough screen to support such a layout? How would you
> know if the server I'm connected to has received the post you're replying
> to, or if it still retains it?

Spoken like a true C++ programmer.

On 14 Sep 2005 12:42:39 -0700, wrote:

>> > You can also switch to a tree view
>>
>> How would you know if my news reader has a tree view or not, or whether my
>> computer has a large enough screen to support such a layout? How would you
>> know if the server I'm connected to has received the post you're replying
>> to, or if it still retains it?
>
>Spoken like a true C++ programmer.

How do you know that?

-dr

"Sherm Pendley" <> wrote in message
news:...
> "John Fullman" <> writes:
>
>> As for my previous post, I was replying to the post above mine.
>
> In my newsreader, there is no post above yours. We're not all (ab)using a
> web browser to access Usenet, you know.
>
Which newsreader are you using? Do you use a PDA?