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