Darren New <dne### [at] sanrrcom> wrote:
> *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.

  Oh, but access rights go beyond simply restricting access from the outside.

  For example, in C++ a base class can have a private member with a certain
name, and a class derived from that base class can have a private member
with the same name. There's no clash. Each class unambiguously accesses its
own member without having to explicitly specify which one with a class prefix.
The private part of the base class really is private: It doesn't even
interfere with a derived class's scope, which might have members with same
names as the base class without problems.

  Also, what naming convention is used in Python for a protected member
variable or function? (In other words, a variable or function which is
accessible by a derived class but not from the outside.)

  Private inheritance is not an extremely common technique in C++, but it
sometimes has its uses (one could think of private inheritance as a kind
of composition where the object itself can act as an object of either the
base or derived class). I suppose there's no such a thing as private
inheritance in Python.

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

  Does the Python standard explicitly state this?

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

  There's this thing called reading comprehension. Understanding what the
other wrote, in its context, rather than nitpicking on words.

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

  The size of an object says nothing about its layout.

  You could as well claim that sizeof(double) tells you something about
how the different parts of a base-2 floating point value are laid out
inside the variable. Of course it doesn't. It just tells how much memory
the type takes, not its internal layout.

  Making a guarantee about the layout of a double would be, for example,
"the most significant bit is always the sign bit".

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

  Actually there's no such guarantee. If you use virtual inheritance in a
diamond inheritance situation, the common base will be shared among the
classes which were multiple-inherited from. This means that the layout
of the objects inside the most derived class will be split, rather than
being at contiguous memory locations.

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

  Sizes say nothing about the layout any more then sizeof(double) says
anything about the internal layout of a floating point number.

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

  But you have no way of knowing the internal layout of B, especially if
A and B have a common base class from which they inherit virtually.

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

  Depends on the debugger. For example programs like valgrind and AQtime
are quite good at catching out-of-bounds accesses, memory leaks and such.
(Of course they can't catch every possible bug, but quite many.)

-- 
                                                          - Warp

Post a reply to this message