POV-Ray : Newsgroups : povray.off-topic : This is the sort of brokenness... : Re: This is the sort of brokenness... Server Time
6 Sep 2024 19:23:15 EDT (-0400)
  Re: This is the sort of brokenness...  
From: Warp
Date: 19 Mar 2009 11:20:41
Message: <49c262c8@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.