kanonische klasse



  • hallo zusammen
    nun habe ich von unterschiedlichen quellen verschiendene aussagen zum kanonischen klassen design bekommen. muss jetzt der destruktor virtuel sein oder nicht?
    ist das kanoische design eigentlich nur ne richtlinie oder gibt es dafür ne regelung?



  • miller_m schrieb:

    muss jetzt der destruktor virtuel sein oder nicht?

    Das hängt davon ab, ob die Klasse als Basisklasse gedacht ist. In diesem Fall ist ein guter Leitsatz: "Der Destruktor einer Basisklasse sollte entweder öffentlich und virtuell oder geschützt und nicht-virtuell sein". Klassen, die value-types implementieren und demzufolge nicht als Basisklassen vorgesehen sind hingegen sollten keinen virtuellen Dtor besitzen.

    ist das kanoische design eigentlich nur ne richtlinie oder gibt es dafür ne regelung?

    Was meinst du damit? Letztlich sind das alles Richtlinien und es gibt immer wieder Situationen, wo man sich nicht an solche Richtlinien hält. Wichtig ist nur, dass man sowas bewusst (und demzufolge mit klaren Gegenargumenten) und nicht ausversehen macht.



  • Welches "kanonische design" meinst du denn?
    Wo kann man das nachlesen?



  • Vielleicht meint er ja "mit Kanonen auf Spatzen schießen" 😃



  • HumeSikkins schrieb:

    Was meinst du damit? Letztlich sind das alles Richtlinien und es gibt immer wieder Situationen, wo man sich nicht an solche Richtlinien hält. Wichtig ist nur, dass man sowas bewusst (und demzufolge mit klaren Gegenargumenten) und nicht ausversehen macht.

    genau das ist das thema 🙂 etwas zu begründen das sich auch etwas stützt wie din, iso, state of art etc.. ist immer einfacher, daher die frage.

    hustbaer schrieb:

    Welches "kanonische design" meinst du denn?

    😕 wie welches?

    [quote="hustbaer
    Wo kann man das nachlesen?[/quote]
    afaik hat zum ersten mal scott meyers über die kanonische form einer klasse geschrieben. folgende implementierungen sollten erfolgt sein.
    - korrekter default konstruktor
    - zuweisungsoperator
    - copy ctor
    - destruktor
    einge beispiele die noch zusätzliche operatoren wie < und == habe ich auch schon gesehen. aber wie schon vermutet gibt es keine allgemein gültig definition der kanonischen form...



  • miller_m schrieb:

    HumeSikkins schrieb:

    Was meinst du damit? Letztlich sind das alles Richtlinien und es gibt immer wieder Situationen, wo man sich nicht an solche Richtlinien hält. Wichtig ist nur, dass man sowas bewusst (und demzufolge mit klaren Gegenargumenten) und nicht ausversehen macht.

    genau das ist das thema 🙂 etwas zu begründen das sich auch etwas stützt wie din, iso, state of art etc.. ist immer einfacher, daher die frage.

    Sich hier auf DIN, ISO oder "state-of-the-art" zu stuetzen ist allerdings auch nicht das Gelbe vom Ei, wenn man nicht weiss, warum es DIN oder ISO etc. ist. Sich blindlinks auf Richtlinien zu stuetzen ohne die Gruende fuer diese Richtlinien zu kennen ist ebenso fehleranfaellig, wie sie aus Ignoranz ausser acht zu lassen.



  • Ich frage welches da ich z.B. für Java eine etwas andere Definition gefunden habe.

    Im Grunde genommen geht es dabei (soweit ich das verstanden habe) nur darum gewisse Minimal-Features festzulegen die man berücksichtigen sollte wenn man eine Klasse implementiert.
    Das heisst nicht dass man in jeder Klasse alles das was die "Vorschrift" verlangt implementieren muss, sondern eher dass man nichts weglassen sollte solange man keinen guten Grund dafür hat.

    Um auf deine Frage zurückzukommen: Wenn man "soll einen (korrekten) default ctor haben" als Forderung zulässt kann man denke ich auch "soll einen virtuellen dtor haben" als Forderung zulassen. Beides ist oft eine gute Idee, und für beides lassen sich unzählige Beispiele finden wo es eine miese Idee ist.

    ----

    Was IMO in C++ wichtig ist: man sollte keine Compiler generierten Funktionen "übrig lassen" wenn diese nicht "korrekt" sind. Also copy ctor und assignment operator private machen wenn sie nicht sinnvoll implementierbar sind. Und selbst implementieren wenn sie sinnvoll implementierbar sind, aber die default generierten Versionen nicht "korrekt" funktionieren würden.

    ----

    Ich habe das Buch von Meyers jetzt nicht zur Hand und kann daher nicht nachsehen wie er das begründet. Würde mich aber interessieren wieso default-ctor und dtor in der Liste vorkommen.

    Der Grossteil meiner Klassen braucht keinen dtor (=der compiler generierte ist ausreichend), und oft genug kommt es vor dass für eine bestimmte Klasse kein sinnvoller default-ctor möglich ist solange man "uninitialisierte Instanzen" vermeiden möchte.



  • hustbaer schrieb:

    Ich habe das Buch von Meyers jetzt nicht zur Hand und kann daher nicht nachsehen wie er das begründet. Würde mich aber interessieren wieso default-ctor und dtor in der Liste vorkommen.

    Ich meine mich dumpf zu entsinnen dass er genau das schrieb was du im vorigen Absatz angemerkt hast, bzw. daraus nochmal explizit The Law of the Big Three/Two abgeleitet hat. (Ist schon länger dass ich den gelesen habe, kann also auch komplette Konfabulation 😉 )



  • Wo erzählt Meyers etwas über kanonische Klassen?

    Anyway, folgendes ist eine kanonische Klasse. C++ ergänzt, was fehlt.

    class Foo {};
    

Anmelden zum Antworten