The most obvious problem is with function overriding.
Let's say have two classes
B, both of which define a method
doSomething. Now you define a third class
C, which inherits from both
B, but you don't override the
When the compiler seed this code...
C c = new C();
...which implementation of the method should it use? Without any further clarification, it's impossible for the compiler to resolve the ambiguity.
Besides overriding, the other big problem with multiple inheritance is the layout of the physical objects in memory.
Languages like C++ and Java and C# create a fixed address-based layout for each type of object. Something like this:
at offset 0 ... "abc" ... 4 byte int field
at offset 4 ... "xyz" ... 8 byte double field
at offset 12 ... "speak" ... 4 byte function pointer
at offset 0 ... "foo" ... 2 byte short field
at offset 2 ... 2 bytes of alignment padding
at offset 4 ... "bar" ... 4 byte array pointer
at offset 8 ... "baz" ... 4 byte function pointer
When the compiler generates machine code (or bytecode), it uses those numeric offsets to access each method or field.
Multiple inheritance makes it very tricky.
C inherits from both
B, the compiler has to decide whether to layout the data in
AB order or in
But now imagine that you're calling methods on a
B object. Is it really just a
B? Or is it actually a
C object being called polymorphically, through its
B interface? Depending on the actual identity of the object, the physical layout will be different, and its impossible to know the offset of the function to invoke at the call-site.
The way to handle this kind of system is to ditch the fixed-layout approach, allowing each object to be queried for its layout before attempting to invoke the functions or access its fields.
So...long story short...it's a pain in the neck for compiler authors to support multiple inheritance. So when someone like Guido van Rossum designs python, or when Anders Hejlsberg designs c#, they know that supporting multiple inheritance is going to make the compiler implementations significantly more complex, and presumably they don't think the benefit is worth the cost.
I am not sure what you are trying to do. You can implement a do-while loop like this:
while not fail_condition:
What are you doing trying to use a do while loop to print the stuff in the list? Why not just use:
for i in l:
So do you have a list of lines? And you want to keep iterating through it? How about:
for s in l:
# use a "break" instead of s = i.next()
Does that seem like something close to what you would want? With your code example, it would be:
for s in some_list:
if state is STATE_CODE:
if "//" in s:
tokens.add( TOKEN_COMMENT, s.split( "//" ) )
state = STATE_COMMENT
tokens.add( TOKEN_CODE, s )
if state is STATE_COMMENT:
if "//" in s:
tokens.append( TOKEN_COMMENT, s.split( "//" ) )
break # get next s
state = STATE_CODE
# re-evaluate same line
# continues automatically
It can be done with a single while loop, but it is not that clear:
Explanation, if d = 0, then d will be 1, also a will be 1. This ends the loop.
Now x is set to a / d which is fine, because if d was 0, a / d evaluates to 1.