![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nicolas Alvarez
Subject: Re: This is the sort of brokenness...
Date: 18 Mar 2009 21:57:04
Message: <49c1a670@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> nemesis <nam### [at] gmail com> wrote:
>> Warp escreveu:
>> > And again, you are hacking on
>> > purpose, trying to bypass the compiler checks, rather than using those
>> > checks to catch your mistakes.
>
>> How this is any different from someone breaking a contract on purpose is
>> beyond me.
>
> It's different because if you do it by mistake, nothing will tell you.
If you're using an underscore-prefixed member in Python, you *know* it's
private. It's not "done by mistake".
Plus, those aren't in the documentation, so you'd have to read the source
code to figure out their names.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nicolas Alvarez
Subject: Re: This is the sort of brokenness...
Date: 18 Mar 2009 22:04:11
Message: <49c1a81b@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Why not? Having the compiler check for breaking of agreements (eg.
> "don't
> access these variables") is much better than oral agreements. The compiler
> is much better at catching mistakes than you are.
It's an underscore or something else clearly visible in the offending
(= private-data-using-) code, not an oral agreement.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nicolas Alvarez wrote:
> If you're using an underscore-prefixed member in Python, you *know* it's
> private. It's not "done by mistake".
Actually, to use C++ terminology, that makes it protected. Two underscores
makes it private. :-)
--
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) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nicolas Alvarez
Subject: Re: This is the sort of brokenness...
Date: 18 Mar 2009 22:06:52
Message: <49c1a8bb@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> Warp wrote:
>> I don't understand what you are saying. If a class in C++ does not
>> expose
>> a member array, then you can't get to that member array from the outside,
>
> int * p = (int *) 0x123456;
> *p = 27;
Undefined behavior.
> How about
> // Your code...
> class xyz {
> public: int[10] x;
> private int y = 0;
> }
>
> // My code
> xyz pdq;
> pdq.x[10] = 27;
Undefined behavior.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nicolas Alvarez
Subject: Re: This is the sort of brokenness...
Date: 18 Mar 2009 22:08:32
Message: <49c1a920@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Deliberately hacking yourself around the compiler checks requires more
> malice than using a public member variable which simply "shouldn't"
> access.
Deliberately accessing a private member through reflection is harder too.
And it's not "malice".
Deliberately accessing a private member by typing its name with the
underscore is not hard at all, but you'll know you're doing it, and if it
breaks it's your fault :)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nicolas Alvarez wrote:
> Undefined behavior.
> Undefined behavior.
Certainly. And that's my point. The C++ standard doesn't say "you can't get
to private members of a class." It says "We're not going to tell you a
reliable and portable way of doing so." That doesn't mean you can't access
private variables - otherwise, we wouldn't have buffer overflows clobbering
private variables in exploits, would we?
--
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) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> > 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?
Actually I'm not saying that. I have nowhere saying that.
I started by defending data hiding principle in the object-oriented/modular
programming paradigm, and stressed that this principle is completely
independent of the language used.
Then somehow you started talking about C++ in particular and somehow the
conversation was drifted from a programming paradigm in general to the quirks
in C++ in particular. I have nowhere defended C++ in particular, but data
hiding in general, as a programming technique.
Your argument against this technique seems to be "since you can't completely
guard against it in C++, it's as good as not having data hiding at all". As
if C++ had anything to do with this issue.
> > 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?
If you write standard-conforming C++, you won't have a wild pointer
(unless you have a bug, of course).
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nicolas Alvarez <nic### [at] gmail com> wrote:
> Instead of using private:, you could just add an underscore to internal
> variables.
But why would I want to do that? There's no benefit. There are only
potential disadvantages.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nicolas Alvarez <nic### [at] gmail com> wrote:
> Warp wrote:
> > And if you don't prevent it, you are locking yourself out of ever trying
> > to improve your module (without breaking tons of existing code).
> Tons of existing code are intentionally accessing stuff they know is subject
> to change?
I still can't comprehend what's so bad in the compiler doing the check
that you don't access the private members.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> I disagree. Now you've got a naming convention that isn't enforced that
> would mean something to people trying to read your code.
You mean the naming convention *is* enforced by languages which do not
explicitly support private data?
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |