Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Again, I disagree. I disagree that C++ refusing to compile when you access 
>> by name something marked as private is significantly more encapsulated than 
>> Python's naming convention that you shouldn't access fields marked with an 
>> underscore by name.
> 
>   Then show me correct C++ which reads a certain private member variable of
> a class, eg. by reading its value to a variable of the same type, without
> the class deliberately exposing it. (Note that the class may have eg. virtual
> functions.)

Do you understand what I mean by "significant"?

Look, you understand what I'm saying, I'm sure. I understand where you're 
coming from. Now you're just trying to tell me my opinion of what's 
important is incorrect, simply because you don't find it to be important.

*I* just don't see any practical advantage of having the compiler enforce 
that. You gave an example from your function library. I contend that the 
same thing could have been done with Python's level of encapsulation. It 
would be no more of an error for me (say) to change how variables that start 
with "_" work than it would be for you to change the size of the class you 
wrote.

*Correct* Python code doesn't rely on "_" members remaining the same from 
one release of code to the next. Just because the compiler doesn't enforce 
it doesn't mean it's "correct".

>>>   There's a huge difference. You make it sound like there was no difference
>>> at all. Just for the sake of argument.
> 
>> In practice, I disagree.
> 
>   In practice? Well, then show me in practice. Some actual code, please.

For what, writing to private variables, or reading from them?  In practice, 
bugs clobber data they shouldn't in unsafe languages.

>> Right. But that's far from "makes no guarantees" you see. You often make a 
>> broad sweeping statement, and when I call you on it, you backpedal and then 
>> say I'm exaggerating "on purpose".
> 
>   You are calling me a liar now? 

No. Merely noting a trend. You don't always say precisely and clearly what 
you mean, and when I give counter-examples, you clarify and then act 
indignant that I addressed what you said instead of what you meant.

>   I might well claim that you "backpedaled" when you first claimed that
> C++ has *no* encapsulation, and later changed it to "little" encapsulation.

I did indeed. It has a small amount of encapsulation, but not enough (IMO) 
to be significant. I granted you that one.

>>>   So you said that "a given type, all by itself, will require sizeof(type)
>>> bytes of memory". Well, duh, that's how sizeof() is defined, after all.
> 
>> You said "there are no guarantees".
> 
>   I was talking about the memory layout of an object. There *are* no
> guarantees about it.

Yes, there are. There's even one I pointed out to which you said "Well, duh, 
that's the definition."  Remember?

You weren't talking about "guarantees about the memory layout of an object." 
You were apparently talking about "guarantees about the memory layout of an 
object that would let you safely and portably access private member 
variables of an arbitrary class without invoking undefined behavior."

And *I* am saying those qualifiers reduce the utility of the form of 
encapsulation that C++ provides.

>> I said yes, there is at least the 
>> guarantee that the elements of a class even with private members are laid 
>> out in the space between the start and the end.
> 
>   You seriously don't understand the difference between "size" and "layout"?

I do. Do you seriously tell me that knowing there isn't data from another 
object between the lowest-addressed private member and the highest-addresses 
private member isn't a guarantee about the layout of the data of a class?

If I take the sizeof a child class, it's always going to be at least as 
large as the sizeof a parent class. If I have a class with two members of 
class X, it's going to be at least twice as large as class X, even if that 
means there are two vtable entries where one would be enough. If I have 
class X that inherits multiply from class A and class B, I know that I can 
take a pointer to class B and not worry that there are bits of A mixed up 
inside.

What you're seeing as "so obvious it doesn't need to be mentioned" is 
exactly what I'm saying are the guarantees. :-)  These sorts of things 
certainly aren't guaranteed in any number of other languages. (For example, 
IIRC, member variables in C# that are shared amongst multiple lambda 
expressions in the same class wind up being allocated in an area outside 
what would be the "sizeof" area of an instance of the class they're declared 
in, because they have to outlast the actual instance variable.  Again, IIRC.)

>   Then, as said in earlier posts, there are no languages with encapsulation
> because you can't physically protect data from being corrupted. There can
> always be a glitch somewhere that corrupts it.

I'll grant you that there are no language implementations on real computers 
that guarantee 100% encapsulation. However, that doesn't mean that any 
amount of encapsulation is equivalent to any other amount.

What's more isolated? A thread, or a process, or multiple independent 
processes all running in the same address space? Well, certainly, if all 
your code is 100% correct, you don't need separate processes at all, right? 
All you have to do to keep from having to reboot your 8086 is just write 
correct code, and no problem.

You may argue that encapsulation hasn't anything to do with correctness. I 
disagree. That's OK. We can agree not to agree on that point.

>   (By your principle of "if it can't be protected from everything it's not
> worth protecting at all",

That's not my principle. My principle is "if you write your combination on 
the outside of the lock, it's not a very secure lock."  Sure, it has all the 
attributes of a good lock, and it might be impossible to pick, but I'll take 
the one that doesn't come with the combination painted on it.

>   You don't use a debugger to resolve where the crash happens?

That's the thing, see. When someone comes along and stomps all over the 
stack, you can't really prove what's happening very easily, even with a 
debugger.

I suppose if we went out and bought a few hundred thousand dollars worth of 
hardware debugging hardware, JTAGs and stuff like that, we could find who is 
writing outside the stack. Unfortunately, clobbering stuff you shouldn't 
clobber doesn't really cause a detectable error until much later sometimes.

More importantly, there's no way to ensure that *your* code isn't clobbering 
*their* code, so there's always an excuse not to look at it if it works for 
their test code.  I.e., if there's a bug in my code that clobbers their 
private/static variables before they even get called, the same symptoms 
might manifest.

Unfortunately, running a device driver under a debugger works poorly without 
hardware support. Plus, we barely fit the system under test in the address 
space, let alone the debugger as well.

Apparently the entire industry is this screwed.  Which would certainly 
explain why in the time the phone system has evolved from cell phones that 
take two hands to carry into iPhones, the set top box industry still can't 
get digital video or even web pages onto the television.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message