Nicolas Alvarez wrote:
> Darren New wrote:
>> No. Making it safe and not making everything public and not needing naming
>> conventions is best. That's what CLOS does, modulo reading the source and
>> invoking interpreter-internal routines with the names of private
>> variables. That's what C# does, modulo the reflection libraries. That's
>> what C++ does, modulo using pointers and UB.
> 
> That's not a good comparison.
> 
> C# has a way to access private data through reflection. Python has a way to
> access private data by just doing it (but you'll know you're doing it
> because there is an underscore).
> 
> C++ has no way to access private data.

memcpy. Check the standard under 3.9. It's therein defined how you can 
access and modify the private data of a class in C++ (and in a 
standards-conforming way if it's POD). Consider the case of "class alpha 
{int abc;}" for a counter-example - I know exactly how that's laid out due 
to the standard. It's perfectly standard-conforming to pass a pointer to an 
instance of class alpha to both memcpy and memset.

In any case, C++ *DOES* in *practice* have a way to access private data, 
even without that, because it's not safe. It's not clean and portable, but 
if there wasn't any way to access private data, we'd have far fewer sigsegv's.

I guess there's two ways you could argue it:
1) C++ in theory disallows access to private variables but in practice every 
known implementation allows it, because it's actually virtually impossible 
to follow the rules of the standard while disallowing said access.
2) LISP in theory allows access to private variables even though it's 
impossible to do by accident and you have to read the source for the 
implementation of the class (which you might not have) to learn the 
variables. (Actually, has anyone checked whether the Common Lisp standard 
actually guarantees you'll be able to get to private variables, or is that 
just the current implementations?)

Sure, in theory, great.

In practice, nobody uses a C++ compiler that prevents access (intentional or 
otherwise) to private variables, and in practice, nobody uses private 
variables of a class that haven't been exported except as a last resort.

Since we're talking about practical benefits (like being able to modify 
code), I was taking the latter approach.

In any case, even if we took reflection out of C# and Java, it's still 
possible to declare unsafe pointers in C# and "native code" in Java that can 
change private variables in a more-or-less well-defined way. Except you're 
now doing it exactly the same way as C++ would, except for the fact that 
again you've flagged your source code as "hey, I'm doing this on purpose". 
I'm not sure how that should "count".

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