Warp wrote:
>   That's a hilariously bad example 

I was assuming you're smart enough to generalize what I'm saying here.

>>   And you're either screwed, or you bypass the private part to 
>> make it work knowing you'll break on the next release of the library.
> 
>   And exactly how would making the private members public help this?

If you could go thru the list of private variables and store the values, 
then later reassign them to how they were, you're golden, yes?

>>>   I disagree. There's no modularity if you can't enforce access rights.
> 
>> And you can't enforce access rights in C++, because nothing prevents wild 
>> pointers from clobbering anything in memory.
> 
>   You are nitpicking, and you know it.

No, I really don't understand. You seem to be arguing that a universal 
naming convention isn't sufficient to say you have encapsulation, but a lack 
of ability to keep others from changing your private variables by accident 
is not a hindrance to encapsulation.

You seem to be saying that it's "unmodular" to say you can only violate 
encapsulation on purpose via complex library routines intentionally designed 
for metaprogramming, but it's modular to let people violate encapsulation by 
accident?

>   If you write normal, standard-conforming C++, you can perfectly well
> enforce access rights.

Um, no, really, you can't. How do you prevent me from corrupting your 
private variables with a wild pointer?

class Alpha {
   int abc = 0;
   public: int get_abc() { return abc; }
}

You're telling me it's impossible for anyone to write code that would ever 
make an instance of Alpha ever return anything but zero when calling 
get_abc()?  Really??

If I do
   Alpha beta;
   memset(&beta, 33, 4);
   std::cout << beta.get_abc();
I'm still guaranteed to get a 0 printed? How did I violate the standard?

By "standard-conforming", do you mean "never accidentally have undefined 
behavior, like using a pointer after you've freed it"?

And the standard that you don't access other instances variables that start 
with an underline doesn't count as "standard-conforming"?

Note that if by "standard-conforming" you mean "never making a mistake", 
it's not *your* code that makes the mistake. It's someone else's. So now 
you're back to trusting everyone to not make mistakes in order to enforce 
encapsulation, aren't you? You can't enforce it on your own.

I'm really trying to understand here, ya know. I'm trying to get my head 
around it. Maybe I've just been away from compiled languages too long or 
something.

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message