|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |