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.

There's a certain subset of valid C++ programs that don't change private 
instance variables from outside the class, namely those that don't 
accidentally invoke undefined behavior. And there's a valid subset of C# 
programs that don't change instance variables from outside the class, namely 
those that don't use the reflection libraries. Which do you think is harder 
to inspect to see what type of program you have?

>>>   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;
> 
>> Find the bug in your code that's setting that member variable to 27.
> 
>   What member variable?

Whichever one my code just accidentally clobbered. If

> 
>> 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?

>   It enforces it as long as you don't deliberately try to bypass the
> compiler checks.

No. It enforces as long as you don't *accidentally* bypass the compiler 
checks at runtime. That's my point!  You *can* accidentally bypass the 
compiler checks.

>   Deliberately hacking yourself around the compiler checks requires more
> malice than using a public member variable which simply "shouldn't" access.
> 
>   It sounds like you are saying "since you can't enforce the privacy of
> the members in all possible cases, then they might just as well be public".
> That's BS.

No. I'm saying that in many of these types of languages, including C#, you 
can enforce the privacy except in cases where the caller goes to extreme 
lengths to bypass that privacy. You don't seem to like the idea that 
reflection violates encapsulation, but you seem perfectly happy with the 
idea that out of bounds array indecies violate encapsulation, simply because 
the standard doesn't say it enforces encapsulation in that case.

>>  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?

>> 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.  In Python, you put "export" in front 
of the list of names of public functions, and you don't put "export" in 
front of the list of names of private functions.

>> Or, in short, you can't protect against bad programmers
>   So let's deliberately make bad code?

No. You're assuming the C++ programmers only write standard-conforming code 
and never accidentally (or maliciously) bypass the type system with a 
runtime bug like a dangling pointer.

Yet you assume the programmer will use reflection to bypass encapsulation 
without understanding the drawbacks, or accidentally use a well-marked 
private variable, and thus encapsulation is broken.

It's a bit of a double-standard there, I think. That's why I'm a bit 
confused. I think I'm seeing what you're saying: I think you're saying 
"Ideally, you can't bypass C++ private on purpose in a portable and 
standards-conforming way, while C# et al give you a standard way of doing 
so."  In my experience, this isn't nearly as helpful a distinction as you 
seem to have experienced.

-- 
   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