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 could just invent a completely wild answer to that argument of yours as
well: "But loops use loop variables without the need of any hacking." It
makes exactly as much sense to me.

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

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

> >   If you need to tell someone else "don't access member variables whose
> > name start with an underscore", that's just plain stupid. You should be
> > able to tell that by making the *compiler* enforce it.

> I agree, except for the fact that you're using C++ as an example. :) C++ has 
> it's own different lack-of-modularity problems. If the compiler actually 
> *enforces* that the member variables you declare private can only be changed 
> by your own methods, that's great.

  It enforces it as long as you don't deliberately try to 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.

> In other words, if they really need to violate the privacy of 
> your class, they're going to do it in C++ almost as easily as they do it in 
> something like Python or LISP.

  Haha.

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

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

> There are also a whole bunch of assumptions in your classes that someone is 
> going to rely on that you're not going to be able to prevent. SimCity 
> assumed memory you called free() on would still be valid until the next 
> malloc(), which is obviously a bad assumption yet still has to be supported 
> by the infrastructure if you expect to run simcity on later versions of the 
> OS.

  I don't see any connection between that and the current subject.

> Or, in short, you can't protect against bad programmers

  So let's deliberately make bad code?

  That's exactly as silly as saying that it's useless to lock your car
because someone could break its windows anyways.

-- 
                                                          - Warp

Post a reply to this message