Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>>   How is it encapsulation if everything is public?
> 
>> """
>> A language construct that facilitates the bundling of data with the methods 
>> operating on that data.
>> """
> 
>> Again, it's the definition you pointed to.
> 
>   Only if you ignore the data hiding part, which is essential for
> abstraction.

Really, Python isn't noticeably less private than C++. C++ shows you 
everything. The compiler says "don't reference that by name", instead of the 
IDE doing it.

>> It has so little encapsulation (in the "restricting access" part of the 
>> definition) that it might as well not have encapsulation.
> 
>   You are exaggerating. On purpose.

I disagree. I'm simply expressing an opinion that differs from yours. If I 
know something is private, I don't try to access it.

>> In other words, I find that marking something as "private" doesn't give 
>> significantly more protection to private data than marking something with an 
>> underline does in Python, in practice. In practice, both are trivial to get 
>> around, accidentally or on purpose.
> 
>   You are exaggerating. On purpose.

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.

>   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. I recognize the difference. I'm just of the opinion 
that the difference is so small as to be irrelevant. You think that having 
the compiler complain is important. I don't.

Do you think Java doesn't have private members because there's a way of 
accessing them via reflection?

>   I don't think the C standard guarantees how much padding there will be
> between members of a struct either. The bit representation of a struct
> instance may change from system to system, and even from compiler to
> compiler, and hence you must not make assumptions if you want your program
> to be portable.

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

>>>> The elements of a structure are all between 
>>>> &x and &x + sizeof(x).
>>>   No, they aren't. The standard doesn't specify how much padding there may
>>> be between struct elements. The compiler can add as much padding as it wants
>>> (or none at all).
> 
>> That doesn't invalidate the formula. I didn't say there was nothing else there.
> 
>   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 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.

What you mean to say is "there aren't enough guarantees on layout to ensure 
that you can do something reasonable in a portable way by breaking 
encapsulation."  That's far different from "there are no guarantees."

You exaggerate, on purpose. ;-)

>   (That doesn't mean you can't have a pointer pointing to a member of an
> object, in a portable way. However, that requires either for the member
> to be public or for the object to give you the pointer.)

Yep. Fully agreed.

>> I didn't say that it did.
>   But we are talking about accessing private members here.

I can still do that. I can't do something *useful* with them, but *in 
practice*, I can zero out your object by mistake. You may discount that as 
irrelevant, but I don't. I don't think that any amount of definition 
wrangling is going to resolve *that* disagreement.

Unsafe languages don't keep code from accessing your private variables. They 
keep you from reliably portably accessing private variables in a correctly 
written system where every piece is bug free.  You're taking the latter to 
mean the former. I'm not.

>>  And besides, I'm just disputing your assertion 
>> that the language makes no guarantees about the layout of data.
> 
>   Well, it doesn't. Not any that would help you accessing them from the
> outside if they are unexposed.

See what you did there?

>   (Btw, I didn't mean "doesn't give any guarantees whatsoever". I meant
> "doesn't give any guarantees that would help you resolving the address of
> a private member from the outside in a portable way".)

OK. I'll agree with that. :-)

>   But if you had, for example, an array of two unsigneds, I'm not sure the
> standard guarantees they will be at consecutive memory locations, with no
> padding between them. (I could be wrong on this one, though.)

I'm not sure.

>   Not that any compiler in the universe would put padding between them,
> mind you, but it's probable that the standard doesn't *force* compilers
> to not to use padding (eg. because an exotic hardware requires it).

Certainly there are machines where floats, for example, need to be on 
particular boundaries and which might not be packed to those boundaries. 
Stupid design, but conceivable. :-)  Of course, on such machines, you 
usually can't get a C compiler.

>   Well, if "access" means "reading their bit pattern in memory", then yes,
> you can "access" them portably.

And, as I said, you can overwrite them, which *I* feel violates 
data-security encapsulation.

>   To me, accessing means that you actually read (or even write) a private
> member variable and write code which depends on it. 

OK. And to me, "accessing" means reading it or writing it without going thru 
the interface defined by the class.

>> memcpy(myarray[0], myarray[1], sizeof(myarray[0])) isn't well-defined? 
> 
>   Only in a very limited set of cases, actually. If myarray consists of
> class instances, the result is undefined behavior (because you are
> bypassing copy constructors).

Fair dinkum.

>   With basic types it's well-defined, and maybe for PODs with trivial
> constructors and destructors.

And for structs or classes with no vtable, as those are defined to have the 
same layout as in C, and it works in C, yes?

>   Well, C++ doesn't stop you from reading the bytes of an object in memory.
> Nobody is denying that.
> 
>   Whether that constitutes "accessing a private member" is arguable.

Right. I think it is, because if you can change the values of my private 
variables without going thru my member functions, I have no way of enforcing 
my code's correctness or my invariants.

>>>   You mean C++ is causing problems there?
> 
>> Oh, you wouldn't believe. Not C++ per se, but unsafe languages in general, 
>> poorly organized and badly documented.
> 
>   Safe languages never cause problems, then?

Safe languages merely make it easier to prove who has the bug. It also tends 
to catch the bug when (say) you open the file, instead of 10 minutes later 
when you try to parse what you read from it.

>> Yep. Well, honestly, the whole development chain is screwed. Not only is the 
>> code buggy, but the authors are unwilling to fix it, describe it, document 
>> it, or really take any responsibility at all for its sorry shape.
> 
>   I'm not sure using a "safe" language would fix those problems either.

Not completely, no. But at least you could assign blame. Right now, if I 
write code that invokes their libbrary and it segfaults, yet it doesn't 
segfault in their trivial test application that only ever invokes one 
operation in the library before exiting, then it must be my fault.

In a safe language, you could say "Look, it throws an exception in your code 
. Find where that exception is, and see what causes it."


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