3. Properties in C++

Properties in C++

  • U

    Hallo Leute,

    ich finde in C++ sollte es wie in C# auch Properties geben.
    Oder kann man sich da, was ich vielleicht noch nicht weiß weiter helfen?

    Dankeschön an alle, die mir helfen wollen.

    0
  • M

    Nee, ich würd ehrlich gesagt keine neuen Sprachfeatures nur wegen syntactic sugar haben wollen. Die Sprache ist schon überladen genug.
    Andere Möglichkeiten gibts genug, z.B. eine Funktion, die Referenzen zurückgibt. Obs eine gute Idee ist, ist eine andere Frage.

    0
  • T

    Warum das?

    0
  • A

    Welchen Vorteil hätte man denn?

    0

  • Man braucht die auch nicht wirklich. Unter Borland/Codegear/Embarcadero hat man das über das proprietäre __property Schlüsselwort implementiert. Und es scheitert grandios an Referenzen und const-correctness. 👎

    0
  • ?

    Jeder der mal mit C# gearbeitet hat, hätte diese Frage("Welchen Vorteil hätte man denn?") nicht gestellt. Ich persönlich vermisse es auch.

    0

  • und_ich_so_hää schrieb:

    Jeder der mal mit C# gearbeitet hat, hätte diese Frage("Welchen Vorteil hätte man denn?") nicht gestellt. Ich persönlich vermisse es auch.

    I beg to differ. Properties sind ja nur Syntaxzucker für Getter und Setter, die man in einem ordentlichen Design sowieso von vorn herein nicht hat. Wieso man Sprachsupport dafür braucht, ist mir bis heute ein Rätsel... 😉

    0
  • T

    und_ich_so_hää schrieb:

    Jeder der mal mit C# gearbeitet hat, hätte diese Frage("Welchen Vorteil hätte man denn?") nicht gestellt. Ich persönlich vermisse es auch.

    Dem kann ich nicht zustimmen. Gute Designs haben keine symmetrischen Setter und Getter und damit sollten die meisten Properties eh nur lesbar oder nur schreibar sein. Wo siehst Du einen Vorteil von:

    const auto a = foo.property();
foo.property( a );

    gegenüber:

    const auto a = foo.property;
foo.property = a;

    ?

    0
  • D

    Torsten Robitzki schrieb:

    Wo siehst Du einen Vorteil von:

    const auto a = foo.property();
foo.property( a );

    gegenüber:

    const auto a = foo.property;
foo.property = a;

    ?

    Hier liegt der Fehler im Ansatz.
    Letztere Syntax kann ich in C++ auch ganz einfach über public-Attribute haben,
    was bei exakt dieser Nutzung wohl auch angebracht wäre.
    Bei der dargestellten Syntax ist nicht davon auszugehen, dass das Attribut ein Implementationsdetail ist, sondern zur Schnittstelle gehört, was öffentliche Sichtbarkeit rechtfertigen würde.

    Natürlich gibt es Ausnahmen:

    1.: Sollen Nebeneffekte auftreten (Sanitychecks, Statistikzähler, Synchronisation, ...),
    so könnten Setter und Getter hierfür notwendig sein.
    Möglicherweise könnte man das aber auch über Decorator um die Attribute modellieren.

    2.: Die Property stellt kein reales Attribut dar. Man könnte die Länge eines Vektors als Read/Write-Property definieren.
    In diesem Fall gäbe es nicht notwendigerweise ein Attribut length, da sich diese aus Anfangs- und End-Iterator errechnen lässt (Getter). Der Setter wiederum könnte die Größe des Vektors verändern.
    An dieser Stelle hätte man dann tatsächlich etwas netten Syntaxzucker, man stelle sich folgendes vor:

    std::vector<int> foo { 23, 42 , 1337 };
foo.length = 2; // yiha
foo.resize(2); // old school

    Allerdings könnte man hier argumentieren, dass komplexere Funktionalität vielleicht nicht auf den ersten Blick wie eine einfache Zuweisung aussehen sollte. Immerhin reden wir von C++ und Dinge, die teuer sind, sollten eventuell auch teuer aussehen...

    3.: Es gibt eine abstrakte Schnittstelle, welche lediglich vorgibt, dass es diese Property gibt, aber nicht, wie diese umgesetzt ist.
    DerivedA könnte hier einfach ein Attribut nutzen, während DerivedB die Property über eine komplexe Berechnung liefert. DerivedC wiederum wuselt auf dem Dateisystem herum.
    Auch hier möchte ich auf die Bedenken von 2. hinweisen.

    Properties sind generell recht angenehm. Unter anderem könnte man default Getter und Setter generieren lassen. Neben der Sichtbarkeit (public/private/protected) hätte man noch Readonly, Writeonly und Readwrite... Und man könnte komfortabel Nebeneffekte einbauen.
    Die Frage ist nur, ob sie das wert sind.
    Braucht man das wirklich? Macht es C++ besser verständlich?

    0
  • S

    http://accu.org/index.php/journals/255

    Properties sind nur Syntax-Zucker. Sie haben selber keinen Mehrwert. Sie sind dann relevant wenn man mittels Reflection und Introspection den Code dynamisch angreifen kann, dann haben sie ploetzlich semantischen Wert. In C++ ist das aber nicht der Fall.

    0
  • F

    Shade Of Mine schrieb:

    http://accu.org/index.php/journals/255

    Properties sind nur Syntax-Zucker. Sie haben selber keinen Mehrwert. Sie sind dann relevant wenn man mittels Reflection und Introspection den Code dynamisch angreifen kann, dann haben sie ploetzlich semantischen Wert. In C++ ist das aber nicht der Fall.

    Wobei man mit reflection (zu mindestens in C#) auch auf member/felder zugreifen kann und deren Werte verändern.
    Wobei üblicherweise im kontext von Databinding C# properties verwendet werden.

    0
  • I

    Shade Of Mine schrieb:

    Properties sind nur Syntax-Zucker. Sie haben selber keinen Mehrwert.

    Das gilt auch für Lambda-Ausdrücke. Manchmal reicht es schon als Grund, dass der Code schöner wird. Also als einziges Gegenargument würde ich das nicht stehenlassen wollen.

    0

  • ipsec schrieb:

    Shade Of Mine schrieb:

    Properties sind nur Syntax-Zucker. Sie haben selber keinen Mehrwert.

    Das gilt auch für Lambda-Ausdrücke. Manchmal reicht es schon als Grund, dass der Code schöner wird.

    Nun, der Punkt ist ja, dass sie den Code eben nicht schöner machen, sondern schlechten Stil propagieren... 😉

    0
  • S

    ipsec schrieb:

    Shade Of Mine schrieb:

    Properties sind nur Syntax-Zucker. Sie haben selber keinen Mehrwert.

    Das gilt auch für Lambda-Ausdrücke. Manchmal reicht es schon als Grund, dass der Code schöner wird. Also als einziges Gegenargument würde ich das nicht stehenlassen wollen.

    Nein, Lambda Ausdrücke sind semantisch etwas anderes - sie lassen sich ja auch komplett anders implementieren als Funktionszeiger. Bieten somit dem Compiler auch ganz andere Optimierungsmöglichkeiten.

    0
  • H

    Shade Of Mine schrieb:

    Nein, Lambda Ausdrücke sind semantisch etwas anderes - sie lassen sich ja auch komplett anders implementieren als Funktionszeiger. Bieten somit dem Compiler auch ganz andere Optimierungsmöglichkeiten.

    Trotzdem ist ein Lambda doch nur eine Kurzschreibweise für einen Funktor?

    dot schrieb:

    Nun, der Punkt ist ja, dass sie den Code eben nicht schöner machen, sondern schlechten Stil propagieren... 😉

    Kannst du erklären was du damit meinst?

    Ich habe oft Sachen wie zum Beispiel:

    class A
{
	int value; // Immer größer als 0
public:
	int getValue() const { return value; }
	void setValue(int newValue) { assert(newValue > 0); value = newValue; }
};

    Wieso sollte das schlecht sein?

    0
  • Mod

    happystudent schrieb:

    Trotzdem ist ein Lambda doch nur eine Kurzschreibweise für einen Funktor?

    Ja, aber Compiler haben spezielle Verfahren um Lambdas zu optimieren. Bspw. können in einigen Szenarien die Captures weggelassen werden und stattdessen nur der ESP gespeichert.

    0
  • H

    Arcoth schrieb:

    Ja, aber Compiler haben spezielle Verfahren um Lambdas zu optimieren. Bspw. können in einigen Szenarien die Captures weggelassen werden und stattdessen nur der ESP gespeichert.

    Hm, aber ist das nicht ein Implementierungsdetail?

    Oder anders gefragt: Der Compiler könnte diese Optimierung dann ja wahrscheinlich auch mit einem entsprechend implementierten Funktor durchführen. Dass er es nicht macht ist dann aber kein Vorteil von Lambdas an sich.

    Oder gibt es dafür irgendwelche speziellen Gründe dass diese Optimierungen nur mit Lambdas überhaupt erst theoretisch möglich sind?

    0
  • Mod

    happystudent schrieb:

    Dass er es nicht macht ist dann aber kein Vorteil von Lambdas an sich.

    Doch, genauso wie es ein Vorteil von range-based for ist, dass der end-Iterator zwischengespeichert wird. Wenn dadurch Optimierung erleichtert wird, ist das ein nennenswerter Gewinn.

    0
  • I

    Also wenn man z.B. folgenden Code hat:

    void foo() {
    int i;
    auto add = [&i](int j) { i += j; };
    ...
}

    Dann habe ich das als Syntax Sugar gesehen für (ungefähr)

    void foo() {
    int i;

    struct interner_name {
        int &iref;
        interner_name(int &iref) : iref(iref) {}
        void operator()(int j) { iref += j; }
    };
    interner_name add(i);
    ...
}

    Welche Optimierungen sind jetzt im ersten Beispiel möglich, die im zweiten nicht möglich sind?

    Ich möchte die Diskussion übrigens nicht in Richtung Lambdas abtriften lassen, aber der Punkt interessiert mich wirklich.

    0
  • M

    lambdas ohne capturing kannst du als function_pointer verwenden.
    in deinem fall, kannst du ein klasse/struct local definieren und verwenden.
    wenn du allerdings z.b. die winapi verwendest, wo viel mit callbacks ueber function_pointers realsiert ist, dann kannst du natuerlich keine lokale funktion dafuer schreiben

    0
Anmelden zum Antworten