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

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

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

  You are calling me a liar now? Like, when I said "the standard offers no
guarantees about the layout of a class" I was really meaning "the standard
offers no guarantees whatsoever about the memory layout of any type" rather
than "the standard offers you no guarantees about the layout which would
allow you to access the private members of a class", but later I claimed
otherwise? I was always talking about accessing private members and why
you can't access them in a portable way. Calling me a liar is offensive.

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

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

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

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

  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.

  (By your principle of "if it can't be protected from everything it's not
worth protecting at all", all these "safe" languages are useless. They can't
protect themselves from everything, hence why try it at all? Better, to just
go back to C, then. No useless protection there.)

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

  No, if they or any of the members have a non-trivial copy constructor.

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

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

-- 
                                                          - Warp

Post a reply to this message