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

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

Darren New <dne### [at] sanrrcom> 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

Nicolas Alvarez <nic### [at] gmailcom> 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

Nicolas Alvarez <nic### [at] gmailcom> 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

Darren New <dne### [at] sanrrcom> 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

Darren New <dne### [at] sanrrcom> wrote:
> >   If you trash memory, you are writing non-portable, non-standard-conforming
> > code. All bets are off.

> You're making a mistake that is arguably easier to make than using a name 
> that starts with an underline.

> That's exactly what I'm saying: If you make a mistake, all bets are off. So 
> you're counting on the perfection of every author and contributor to your 
> codebase to always do the write thing, because the compiler *doesn't* check 
> that it's right, and the runtime *doesn't* check that it's right.

  Your argumentation just doesn't make any sense.

  The question here is: Are compiler-enforced private member variables a
good thing in programming or not?

  Your argument why they are not: In C++ you can accidentally access them
regardless of the compiler checks.

  I think that your problem is that you have some kind of holy war against
C++, and every single discussion about programming is always somehow turned
to bashing C++. Thus every time you want to discredit some argument, you
go and explain why that thing is done wrong in C++, regardless of whether
C++ in particular was being discussed, or whether it was a more generic
discussion about programming.

  I defended data hiding in general, as a programming paradigm (and I made
that pretty clear). Your very first reply to me was a reference to (and
attack against) C++. You certainly didn't wait. Now you have succeeded in
dragging this thread away from the original question, and made it about
access rights in C++ and why everything is better in all other languages.

  I'm honestly getting tired of your C++ tirades. Every single subject
related to programming must somehow include C++ bashing, regardless of
the subject. That's getting tiresome.

  I'm also getting tired of you twisting what I say. I have admitted that
in C++ you can trash memory, triggering undefined behavior which might,
among other things, modify the state of an object. You somehow have managed
to twist this so that, according to you, I'm saying this is a good thing
(or somehow "better" than other means of accessing private members). I can't
understand where you are getting this. You are just arguing for the sake of
arguing. Example:

> >   Where have I said "there should be a non-portable way to bypass it"?
> > 
> >   There may be a non-portable way of bypassing it. That's different from
> > "there should be".

> So you're saying having non-portable ways of bypassing the typing is better 
> than having portable ways of bypassing the typing?

  How do you even manage to twist my words to almost the exact opposite of
what I'm saying?

  Where exactly do you see the word "better", or any kind of synonym or
reference to it? That's completely your twisted invention.

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> 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.

  Ok, "written agreement" then, if you want to nitpick. Not much difference.
Still not enforced nor sanity-checked by anyone or anything.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >>> (Well, at least not without some serious hacking.)
> > 
> >> Running off the end of an array is "serious hacking"? I wouldn't think so.
> > 
> >   Now I'm completely puzzled. We are talking about public interfaces and
> > private members, and you start suddenly talking running off the end of an
> > array? I can't see *any* connection whatsoever between these two things.

> I'm saying that C++ does not enforce that you don't change private instance 
> variables from outside the class.

  And this has exactly what to do with whether (compiler-enforced) data
hiding is a good thing or not?

  Every single discussion about programming with you turns into C++ bashing,
no matter what the subject.

> >> How about
> >> // Your code...
> >> class xyz {
> >>    public: int[10] x;
> >>    private int y = 0;
> >> }
> > 
> >> // My code
> >>   xyz pdq;
> >>   pdq.x[10] = 27;
> > 
> >   You are accessing a public variable, not a private one.

> Nope. Read it again. What exactly gets set to 27?  Do you think there's a 
> good chance it might by y?

  You are accessing a public variable, namely the array named 'x'.

  You are accessing it out of boundaries, triggering UB, after which the
compiler is free to do whatever it wants with your code. It may as well
draw an ascii mandelbrot for all the standard cares.

  Could that perhaps change 'y'? Maybe. The standard allows the compiler
to do whatever it wants. If the compiler wants to change 'y', it has the
standard's blessing. If the compiler gives you an error message saying that
you are a moron, that's ok as well.

> >>  The compiler doesn't enforce the 
> >> encapsulation in C++ - it just gives warnings when you use a variable name 
> >> that's private.
> > 
> >   Warnings? Trying to access a private variable gives a compiler error.

> Only if you do it in the obvious way. Or are you saying there's a 
> compile-time warning for calling memset() with too large a size?

  I'm just baffled about how you twist words. Exactly where am I saying
anything like that? I don't even understand how you can come with such a
conclusion. It doesn't make any sense.

"The compiler doesn't enforce encapsulation, it just gives warnings."
"Actually the compiler gives an error if you try to break encapsulation."
"Are you saying there's a compile-time warning for calling memset wrongly?"
"???"

  I just can't follow your logic.

> >> Granted, if you don't *document* in a universal kind of way what's public 
> >> and what isn't, you're leaving yourself open to abuse.
> > 
> >   That's the great thing about language support for private sections: You
> > don't *need* to document that they are private. The compiler will tell you.

> Sure you do. You have to put "private:" in front of the private bits and 
> "public:" in front of the public bits.

  Exactly how is that "documentation"? That's source code.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> or the infamous "#define private public"

  Btw, if you *really* want to hide your private variables, there's a
technique used by some:

class MyClass
{
 public:
    // public functions here

 private:
    struct Members;
    Members* members;
};

  If the struct 'Members' is implemented eg. in a static or dynamically
loadable library, ie. you don't have the source code, it's extremely
difficult for anyone to even figure out what members there are in there
or how to access them. Your #define won't help at all here, nor accessing
the object by other means.

  You could, of course, take that pointer and start trashing the memory
it's pointing to, but that would be rather pointless. Certainly not useful.

-- 
                                                          - Warp

Post a reply to this message