Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   *That* is the beauty of encapsulation.

> OK. So you agree that Python also has encapsulation?

  Does the compiler enforce it?
> >   Do you really think that the compiler telling you "you must not access
> > this member, I refuse to compile it" is not a better way to enforce
> > encapsulation than just some documentation that nobody is going to read
> > anyways? 

> Not if you're not going to enforce it the other ways as well.

  Right. So if it's possible to modify the data by having some wild pointer
bug in the program, then it's not worth having compiler checks at all and
just have everything public.

  As you said, we'll just have to agree to disagree.

> >   If you must have "visible" members in the class declaration for technical
> > and/or efficiency reasons, it's better if the compiler offers a tool for
> > telling the user "even though you can see this you really shouldn't be
> > referencing it directly" rather than relying solely on a comment line.

> Sure. What about a naming convention that "comes with the language"? I.e., 
> not just a naming convention you made up, but one in common for every single 
> program written in the language from day one?

  By that reasoning you could argue that C is an object-oriented language.
After all, you can get OO'ish behavior if you follow certain coding
conventions.

> >   So yes, it's much better if the compiler tells the user he is accessing
> > what he shouldn't.

> I agree it's better. But since you seem to like binary definitions, and you 
> don't like me saying "C++ has a little bit of encapsulation but not much", 
> I'm curious if you think that (say) Python has encapsulation, given that 
> everyone knows that names with _ are private to the class they're in?

  How is it encapsulation if everything is public?

> >   But where do you draw the line between what is and isn't encapsulation?

> I don't make it a binary choice. I say "C has no encapsulation, Python has 
> very little (more modularity than encapsulation), C++ has a little more than 
> Python (because the compiler refuses to compile stuff that violates the 
> language rules)

  That actually contradicts what you said originally. Originally you said
that C++ has *no* encapsulation. Clearly you were drawing a clear line
somewhere.

> >> In contrast, C++ has well-defined mechanisms for bypassing the encapsulation 
> >> that are used as a normal part of programming in that language.
> > 
> >   Actually it doesn't. You can read the binary representation of an object
> > in memory, but the standard gives no guarantees as to which byte means what.

> I don't believe that's true. It certainly wasn't in C.

  What wasn't in C?

  As for the C++ standard, it does certainly not give any guarantees about
the bit representation of objects in memory. It's implementation-defined.
You can read the bits, but there's no guarantee about their meaning (nor
that the meaning won't change from class to class).

> > The memory layout of objects is completely implementation-defined

> Nonsense. Arrays are contiguous.

  Arrays are not objects. Arrays are a collection of objects.

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

  Also, the standard doesn't guarantee that the first member of a struct
starts from the same memory address as the struct instance itself. (In
practice this can actually differ if the struct has virtual functions.
In that case the pointer-to-struct-instance will not point to the first
member of the struct. There will be some implementation-dependent vtable
pointer there instead.)

  If a member is private, you have no safe, portable way of accessing it
from the outside.

>  There's lots of guarantees. And I'm pretty sure that 
> if you have "struct x {int a; int b} y;" that the standard guarantees
> &b > &a.

  Probably, but if a and b are private, you have no portable way of getting
an address to them. You don't know the offset.

> Positive integers are represented in twos-complement coding. 

  I'm not completely sure the standard guarantees that.

> Unsigned integers occupy the the number of bits indicated by multiplying 
> sizeof(unsigned) by bits_per_char or whatever the appropriate #define is.

  Well, duh, because sizeof(type) is *defined* as telling the amount of
bytes that the type requires.

  That still doesn't help you accessing private data of an object portably.

> Now, if you're going to argue those guarantees don't count, Ok.

  Don't count to what? The issue was whether it's *well-defined* to break
encapsulation in C++. Your own words.

  It's not well-defined. You can try, but the results are not guaranteed.

> >   The standard allows doing that even if it's undefined behavior simply
> > because imposing restrictions on that would mean that compilers would
> > have to generate significantly less efficient code even for programs
> > which don't even attempt doing that. Many people don't mind.

> Can I get you to come work for my company? :-)

  You mean C++ is causing problems there?

  I suppose I should consider myself lucky in that I get to work in
projects where I don't have to go fixing existing code made by incompetent
C++ programmers...

-- 
                                                          - Warp

Post a reply to this message