staging.inyokaproject.org

ryiden schrieb:

Falsch, mit Deinem C++-Compiler lässt sich so etwas nicht übersetzen.

Hier ist ein Working Draft für den nächsten C++-Standard, wobei es Dir natürlich auch freisteht, ein Exemplar des C++03-Standards zu kaufen. Relevant ist hier Kapitel 10.2, "Member Name Lookup". Ich habe Dein Beispiel mal in die C++-Syntax überführt:

#include <iostream>
class KlasseA {
  void print() {
    std::cout << "Hello World" << std::endl;
  }
};
class KlasseB {
  void print() {
    std::cout << "Hello Lunar" << std::endl;
  }
};
class KlasseC : KlasseA, KlasseB { };
int main() {
        KlasseC c;
        c.print();
}

Dieses Programm ist nach den o. g. Regeln "ill-formed", daher muss der Compiler das zurückweisen.

Danke, war ziemlich interessant zu lesen.

Um das ganze nun zu einem Abschluss zu bringen: Im Großen und Ganzen bin ich froh, dass sich meine Fraktion letztendlich doch durchgesetzt hat und es in neueren Programmiersprachen keine Mehrfachvererbung mehr gibt (nicht einmal in den großen C++-Nachfolgern C# und D).

Von mir aus können wir jetzt mit Goto weitermachen. Außerdem habe ich auch noch das Thema Pointer vs. Referenzen anzubieten 😉

@ryiden
Wow, dass ist wirklich ein großes Problem bei Mehrfachvererbung 🙄 In Python ist dass absolut kein Problem wenn man dass Verhalten einmal kennt und wenn man es nicht kennt probiert man es aus.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

class Foo(object):
    def say(self):
        print 'spam'                   
                     

class Bar(object):
    def say(self):
        print 'eggs'


class Baz(Foo, Bar):
    pass

Baz().say()
# spam

class Baz(Bar, Foo):
    pass

Baz().say()
# eggs

Ich muss nochmal auf Seite 6 eingehen. Was das Für und Wider für Python angeht, das wurde hier schon ausführlich erläutert. Lunar schrieb:

bremer schrieb:

Allein Java mit Python zu vergleichen... Python wird auch übelst gehyped und kommt trotzdem nie an Java ran. Und wie C# jetzt eindeutig besser sein soll, sehe ich auch nicht.

Ob du das nun siehst oder nicht, ist für die Faktenlage reichlich irrelevant. Vor allem, wenn du dich nicht im Geringsten bemühst, deine Aussagen mit Erklärungen und Argumenten hinterlegen. Ich kann deinen Satz ohne Probleme umdrehen und in "Java wird übelst gehyped und kommt trotzdem nie an Python heran", ohne das er an Überzeugungskraft verlieren kann. @Quivadis
Plattformübergreifende Entwicklung ist auch mit Python, C++ oder C# möglich. Das ist schon lange kein Alleinstellungsmerkmal mehr (wenn es das denn je war). Das immer die beste Sprache für ein Projekt genommen wird, war und ist leider Wunschtraum.

Python wird vor allem von der Linuxgemeinde, Open-Source-nahen Leuten, sowie Google und Tiobe vermarktet. Die Motive kenne ich nicht. Nicht, dass ich etwas gegen Python hätte, ich nutze es ja selber gerne. Warum Python nicht an Java herankommt, wurde hier auch dargelegt.

C++ und vor allem C# sind bei weitem nicht so plattformübergreifend wie Java!

DasIch schrieb:

In Python ist dass absolut kein Problem wenn man dass Verhalten einmal kennt und wenn man es nicht kennt probiert man es aus.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

class Foo(object):
    def say(self):
        print 'spam'
    def say2(self):
        print 'spam2'

class Bar(object):
    def say(self):
        print 'eggs'
    def say2(self):
        print 'eggs2'

Wie krieg ich jetzt meine "spam eggs2" oder "spam2 eggs"?

bremer schrieb:

C++ und vor allem C# sind bei weitem nicht so plattformübergreifend wie Java!

C# vielleicht, aber für C++ existieren Toolkits wie wx oder Qt4, die komfortabel plattformunabhängige Programmierung ermöglichen. Was graphische Oberflächen angeht, ist Qt4 den Standardtoolkits (Swing, AWT, SWT) weit überlegen. Gegen diese Behauptung spricht auch, dass die meisten der plattformübergreifenden Programme, die du so nutzt (Firefox, Opera, OpenOffice, Adobe Reader, etc.) in C++ geschrieben wurden.

PrairieDog schrieb:

Wie krieg ich jetzt meine "spam eggs2" oder "spam2 eggs"?

Gar nicht.

Ich hab auch noch nie gesehen dass das irgendwo nötig oder sinnvoll wäre, noch kenne ich eine Sprache die dies ermöglicht.

Mehrfachvererbung wird in Python auch nicht allzu oft eingesetzt und wenn es eingesetzt wird, gibt es auch i.d.R. keine brauchbare Alternative.

DasIch schrieb:

In Python ist dass absolut kein Problem wenn man dass Verhalten einmal kennt und wenn man es nicht kennt probiert man es aus.

Wer garantiert Dir, dass sich das Verhalten nicht ändert? Wählt der Python-Compiler zufällig eine der beiden vererbten Klassen aus, immer die Erste, oder immer die Letzte? Ist das Verhalten von Compiler zu Compiler unterschiedlich bzw. von Compiler-Version zu Compiler-Version? Oder was passiert, wenn das Programm von einem Python-Interpreter unter Windows oder auf einem Mac ausgeführt wird.

DasIch schrieb:

noch kenne ich eine Sprache die dies ermöglicht.

C++:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

#include <iostream>
class KlasseA {
public:
 void print() {
   std::cout << "Hello World" << std::endl;
 }
};
class KlasseB {
public:
 void print() {
   std::cout << "Hello Lunar" << std::endl;
 }
};
class KlasseC : public KlasseA, public KlasseB {
};
int main() {
       KlasseC c;
       c.KlasseA::print();
       c.KlasseB::print();
}

Siehe dazu auch: http://de.wikipedia.org/wiki/Zwillingsklasse

Ist die Frage, obs nur darum geht, unvorhersehbares Verhalten zu vermeiden (das würde Python dann wohl trivial lösen), oder Namenskonflikte gezielt zu lösen.

@bremer: Wo wurde dargelegt, das Python nicht an Java herankommt? Ich habe da bisher nur eine persönliche, nicht mit stichhaltigen Argumenten untermauerte Meinung gesehen.

Bei C# magst Du recht haben, aber es gibt sicher mehr Plattformen für die es einen C++-Compiler aber keine JVM gibt. Man denke zum Beispiel an den Embedded-Bereich.

@ryiden: Python's "new-style"-Klassen verwenden den C3 method resolution-Algoritmus, das ist AFAIK auch durch die Dokumentation garantiert.

@e1bart0: Na dann kann Python das wohl auch:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

class A(object):
    def print_(self):
        print 'Hello World'

class B(object):
    def print_(self):
        print 'Hello Lunar'

class C(A, B):
    pass

def main():
    c = C()
    A.print_(c)
    B.print_(c)

Marc 'BlackJack' Rintsch schrieb:

@bremer: Wo wurde dargelegt, das Python nicht an Java herankommt? Ich habe da bisher nur eine persönliche, nicht mit stichhaltigen Argumenten untermauerte Meinung gesehen.

Bei C# magst Du recht haben, aber es gibt sicher mehr Plattformen für die es einen C++-Compiler aber keine JVM gibt. Man denke zum Beispiel an den Embedded-Bereich.

@ryiden: Python's "new-style"-Klassen verwenden den C3 method resolution-Algoritmus, das ist AFAIK auch durch die Dokumentation garantiert.

Ist es: Data Model, Standard Type Hierarchy, Unterpunkt "Classes" (leider gibt es da keine Anker):

New-style classes use the more complex C3 method resolution order which behaves correctly even in the presence of ‘diamond’ inheritance structures where there are multiple inheritance paths leading back to a common ancestor. Additional details on the C3 MRO used by new-style classes can be found in the documentation accompanying the 2.3 release at http://www.python.org/download/releases/2.3/mro/.

Dort ist auch das Verhalten von Old-Style Klassen (die nicht von object ableiten) definiert:

For old-style classes, the search is depth-first, left-to-right in the order of occurrence in the base class list.

Anzumerken sei noch, dass die man die MRO mittels inspect.getmro() auch abfragen kann.

Mehrfachverbung mag in einfachen Beispielen, noch übersichtlich sein, aber sobald man es mit einer komplexeren Verebungshierachie zu tun bekommt, kann von Übersichtlichkeit keine Rede mehr sein. Insbesondere, wenn man es mit der Programmwartung zu tun hat. Der Einsatz ist wirklich nur in Sonderfällen sinnvoll und lässt sich auch da meistens umgehen. Ob der Mangel an Eleganz in solchen Fällen mehr wiegt, als die Garantie nie Probleme mit der Mehrfachvererbung zu bekommen, kann jeder für sich entscheiden. Imho hat sich ein gewisser Simplifizismus zu Recht in großen Projekten durchgesetzt.

Kinch schrieb:

Der Einsatz ist wirklich nur in Sonderfällen sinnvoll und lässt sich auch da meistens umgehen.

Wieso sollte man dass tun? In diesen Fällen verwendet man sie in anderen nicht.