|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |