3. C++ nach ISO Standart

C++ nach ISO Standart

  • H

    Nur wie macht mans richtig ?

    Guck mal, ob du dich mit boost::formated anfreunden kannst. Marc++us scheinbar nicht, ich finde es ganz gut.

    Ist Mehrfachvererbung (ohne das man nen grosses Framework ala MFC,QT,VCL hat) nen gutes Design ?

    Das kommt sehr auf die Verwendung an. Wenn du nur von Schnittstellen erbst (komplett abstrakten Basisklassen), hat keiner was dagegen. Wenn du es verwendest, um Policys einzusetzten ist das für C++-Programmierer meistens auch in Ordnung. Ansonsten gibt's Streit. Die einem meinen es ist OK, andere sagen es ist Mist, man hätte es mit ein wenig Nachdenken auch ohne Mehrfachvererbung hinbekommen. Ich schaffe das nie, ohne mir dann das Interface vieler Klassen vollzumüllen. Allerdings kommt das recht selten vor.

    Ich mein sowas:

    .
       Basis
         |
  +------+------+
Derivat1     Derivat2

    Nun merkst du Derivat2 muss aber noch von Foo erben. Was machst du? Die einzige Lösung mit Einfachvererbung sieht so aus:

    .
        Foo
         |
       Basis
         |
  +------+------+
Derivat1     Derivat2

    Dann ist Derivat1 aber zugemüllt mit irgend 'nem Quatsch, den es gar nicht braucht. Für alle andere Klassen, die man noch von Basis ableitet, gilt das selbe.
    Da finde ich die Lösung mit Mehrfachvererbung wesentlich schöner

    .
       Basis          Foo
         |             |
  +------+------+------+
Derivat1     Derivat2

    Allerdings kommt sowas allgemein extrem selten vor.

    0
  • M

    Man muß sich manchmal auch auf die Bedeutung besinnen.

    Ganz klar: Vererbung heißt "ist ein". Also bedeutet Mehrfachvererbung, daß irgendein Objekt zweimal "ein xx ist". Das kommt vor. Wenn im Modell so ein Objekt vorkommt, dann realisiert man in Gottes Namen das auch mit Mehrfachvererbung, warum nicht. Da man im Modell ja auch ein Abbild von etwas macht, sind die Gefahren wie der Deadly Diamond eher unwahrscheinlich. Trotzdem tut man sich einen Gefallen, wenn man von [siehe Heliums Beispiel] Derivated1 und Derivated2 NICHT mehr weiter ableitet...

    Für Interfaces ist es ohnehin ok, für Frameworks sollte man es auch eher vermeiden, weil man nie so genau weiß was die Leute "unten" in der Hierarchie mit dem Framework noch anstellen.

    0
  • D

    Helium schrieb:

    Da finde ich die Lösung mit Mehrfachvererbung wesentlich schöner

    .
       Basis          Foo
         |             |
  +------+------+------+
Derivat1     Derivat2

    Ist Foo jetzt das, was unter Mixin in der Werbung läuft?

    Marc++us: Dein "völlig legaler Code" von oben, ist leider nicht wirklich konform. (Es gibt C++-Compiler, die spielen da nicht mit [eine Steinzeitversion von Sun mW]).

    0
  • E

    Marc++us: Ich lese den Standard nur, wenn Hume nicht mehr weiter weiß.

    So kann man das auch lösen. 😃

    Ich wollte nur darauf hinweisen, dass man im Standard die verbindlichsten Antworten auf formelle Fragen erhält. Konzeptionelle Lösungen findet man im Standard nicht ausreichend. Dafür gibt es hervorragende Tutorials/Bücher, die hier bereits umfänglich zitiert/gelinkt wurden.

    0
  • M

    Daniel E. schrieb:

    Marc++us: Dein "völlig legaler Code" von oben, ist leider nicht wirklich konform. (Es gibt C++-Compiler, die spielen da nicht mit [eine Steinzeitversion von Sun mW]).

    Wieso das denn nicht?

    0
  • ?

    ist der dev-c++ 4 näher am Standard als mein vc++6.0?

    0
  • ?

    Es gibt keinen Standard für IDEs.

    0
  • D

    Marc++us schrieb:

    Daniel E. schrieb:

    Dein "völlig legaler Code" von oben, ist leider nicht wirklich konform. (Es gibt C++-Compiler, die spielen da nicht mit [eine Steinzeitversion von Sun mW]).

    Wieso das denn nicht?

    Das Semikolon nach dem Funktionsbauch des Konstruktors ist pedantischerweise nicht erlaubt. Außer dem besagten Compiler scheint sich da aber (zurecht) niemand dran zu stören.

    0
  • B

    Daniel E.: Wo steht das? Nach der Grammatik ist eine leere Deklaration in einer Klasse erlaubt. 9.2:

    class-specifier: class-head { member-specification_opt }

    member-specification: member-declaration member-specification_opt

    member-declaration: decl_specifier_opt member_declarator_list_opt ;

    Wenn man pingelig ist, interpretiert man 9.2.1 "... and each such member-declaration shall declare at least one member name of the class" als Zusatzregel zur Grammatik, dann kommt aber die Ableitung

    member-declaration: function-definition ;_opt

    zum Tragen.

    0
  • D

    Bashar schrieb:

    dann kommt aber die Ableitung

    member-declaration: function-definition ;_opt

    zum Tragen.

    Bezieht sich das '_opt' auf das Semikolon oder die 'function-definition'?

    (Falls ich danebengelegen haben sollte, habe ich natürlich absichtlich die Unwahrheit gesagt, um hier direkt vor Ort die Nützlichkeit der C++-Norm zu belegen. [So was muss man sich ausdenken, nur weil man ohne nachzusehen postet. <Sowas aber auch.>]) (dreifache Klammerverschachtelung = ein Smiley)

    0
  • B

    auf das Semikolon

    0
  • E

    @eineFrage: Der Compiler des Dev-C++ (4.9.x.x) ist deutlich näher am Standard als der Compiler des MSVC++6.

    0
  • H

    @Bashar und Daniel E.
    Sehe ich das richtig, dass dieses "Semikolon nach Funktionsdefinition erlaubt" nur *innerhalb* einer Klassendefinition gilt, es außerhalb aber verboten ist:

    class A
{
public:
void func() {}; // erlaubt
void func2();
};

void A::func2() {}; // verboten

    Bitte sagt ja 🙂

    0
  • B

    Hume: Öhm, ich hab zwar letzte Woche noch argumentiert, dass die Grammatik das zuläßt:

    simple-declaration: decl-specifier-seq_opt init-declarator-list_opt ;

    Aber im Text steht, dass die "init-declarator-list" nur weggelassen werden kann, wenn das ganze eine Klasse oder einen Aufzählungstyp deklariert. Schade eigentlich, was ist so schlimm an leeren Deklarationen?

    0
Anmelden zum Antworten