3. klasse datum

klasse datum

  • ?

    Ähh? Das war doch gerade meine Kritik!
    Wenn die einzige Möglichkeit Attribute zu ändern der Konstruktor ist, dann
    muss man die Objekte wohl notgedrungen kopieren.

    Jockel

    0
  • ?

    Dein Edit kam zu spät.
    Okay, das mit dem kopieren war Mist. Trotzdem ist der Aufruf über den Konstruktor weiterhin langsamer, oder?

    Jockel

    0
  • ?

    Nein, denke ich nicht. Der Konstruktor setzt ja im Grunde auch nur die Werte. Vielleicht wäre er langsamer, wenn es noch mehr Datenelemente gibt wie die 3, die wir ändern wollen.
    Aber das ist IMO nichts gegen die Vorteile und Sicherheit, die unveränderliche Objekte bieten.

    0
  • V

    Jockelx schrieb:

    volkard schrieb:

    wozu haste setzeDatum überhaupt? dafür ist der konstruktor
    doch da!

    ???
    Das wundert mich jetzt, das von dir zu hören.
    ...
    Begründe mal bitte deine Ablehnung der Setzefunktion.

    oh, du hat mitgekriegt, daß ich speed-fanatiker bin. das ist fein.

    triviale funktionen sind in der praxis doch inline. da hat der optimierer vollen zugriff, und es ist einfach gleich, ob ich schreibe

    Datum d;
for(i=0; i<1000000; ++i)
{
    leseDatum(tag, monat, jahr);
    d.setzeDatum(tag, monat, jahr);
    machWasMitDatum(d);
}

    oder

    Datum d;
for(i=0; i<1000000; ++i)
{
    leseDatum(tag, monat, jahr);
    d = Datum(tag, monat, jahr);
    machWasMitDatum(d);
}

    oder

    int d[]={1,1,1900};
for(i=0; i<1000000; ++i)
{
    leseDatum(tag, monat, jahr);
    a[0]=tag;d[1]=monat;d[2]=jahr;
    machWasMitDatum(d);
}

    es wird exaktamente der gleiche assembler-code erzeugt.
    solange es bei null-kosten bleibt, feines c++ zu nehmen, soll man das auch tun, finde ich.

    und nu zu besserem beispiel.
    das hier darf keiner schreiben:

    Datum d;
for(i=0; i<1000000; ++i)
{
    leseDatum(tag, monat, jahr);
    d = Datum(tag, monat, jahr);
    machWasMitDatum(d);
}

    d ist viel, viel zu unlokal.
    mußt schon schreiben:

    for(i=0; i<1000000; ++i)
{
    leseDatum(tag, monat, jahr);
    Datum d = Datum(tag, monat, jahr);
    machWasMitDatum(d);
}

    aha, und jetzt apiert sogar der zweitdümmste compiler, daß hier ne returnvalue-optimierung zu greifen hat. es wird nicht ein datumsobjekt erzeugt, davon ne kopie gemacht und das original gelöscht. nee, es wird direkt in den speicher vom lokalen objet d reinkonstruiert.
    schon wieder nullkosten für abstraktion. und der trick geht auch mit größeren klassen.

    0
  • I

    Mal ne kurze Design-Frage, wo wir schon dabei sind:

    Sollte man bei einem Immutable-Objekt überhaupt die Operatoren, die this verändern (+=, *= etc) implementieren?

    0
  • V

    interpreter schrieb:

    Mal ne kurze Design-Frage, wo wir schon dabei sind:

    Sollte man bei einem Immutable-Objekt überhaupt die Operatoren, die this verändern (+=, *= etc) implementieren?

    war mit immutable gemeint, daß man schreiben sollte:

    for(i=0; i<1000000; ++i) 
{ 
    leseDatum(tag, monat, jahr); 
    Datum const d = Datum(tag, monat, jahr); 
    machWasMitDatum(d); 
}

    falls immutable das ist, dann klar, hab das const da vergessen. mit const ist ja alles noch viel sicherer.
    und += und *= sind ja non-const members und würden auf dem const d gar nicht laufen, also kann man sie ruhig implementieren.

    0
  • I

    Wenn man ein Objekt als immutable designt, dann darf man es nach dessen Erzeugung nicht mehr verändern können. Sowas wie X::setY(int y) darf es also nicht geben. Folglich darf ich doch auch operator*= usw nicht implementieren, weil ich sonst das Objekt selbst verändern kann. Ob das Objekt nun const oder nicht is, is doch egal - auch "nicht const"-Objekte dürfen nicht mehr verändert werden.
    BTW:
    Sowas sehe ich zum 1. Mal:

    Datum const d = Datum(tag, monat, jahr);

    Wieso schreibst du das const nach dem Datentyp? Ist das selbe, wie const Datum d? Kann es sein, dass in der Zeile zuerst ein Temporäres Objekt erzeugt wird, das dann per CopyConstructor in d kopiert wird?

    0
  • S

    interpreter schrieb:

    Wieso schreibst du das const nach dem Datentyp? Ist das selbe, wie const Datum d?

    Ja.

    http://tutorial.schornboeck.net/konstanten.htm schrieb:

    Statt int const kann man auch const int schreiben, beides bedeutet das selbe. Allerdings sollte man bei der Variablendeklaration immer von Rechts nach Links lesen, so dass man float const PI so liest: (Die Variable) PI ist vom Typ const float.

    interpreter schrieb:

    Kann es sein, dass in der Zeile zuerst ein Temporäres Objekt erzeugt wird, das dann per CopyConstructor in d kopiert wird?

    siehe Humes FAQ

    0
  • I

    Shade Of Mine schrieb:

    interpreter schrieb:

    Wieso schreibst du das const nach dem Datentyp? Ist das selbe, wie const Datum d?

    Ja.

    http://tutorial.schornboeck.net/konstanten.htm schrieb:

    Statt int const kann man auch const int schreiben, beides bedeutet das selbe. Allerdings sollte man bei der Variablendeklaration immer von Rechts nach Links lesen, so dass man float const PI so liest: (Die Variable) PI ist vom Typ const float.

    interpreter schrieb:

    Kann es sein, dass in der Zeile zuerst ein Temporäres Objekt erzeugt wird, das dann per CopyConstructor in d kopiert wird?

    siehe Humes FAQ

    Danke.
    Da finde ich aber

    const Datum d(tag, monat, jahr);

    wesentlich intuitiver

    0
  • V

    interpreter schrieb:

    Wenn man ein Objekt als immutable designt, dann darf man es nach dessen Erzeugung nicht mehr verändern können. Sowas wie X::setY(int y) darf es also nicht geben. Folglich darf ich doch auch operator*= usw nicht implementieren, weil ich sonst das Objekt selbst verändern kann. Ob das Objekt nun const oder nicht is, is doch egal - auch "nicht const"-Objekte dürfen nicht mehr verändert werden.

    aha. und wozu macht man sowas?

    auf jeden fall ist immutable für Datum-objekte unfug. Datum muß genauso praktisch wie time_t sein. Ware einfach störend, statt d=d+14 nicht mehr d+=14 schreiben zu dürfen.

    0
Anmelden zum Antworten