Properties in C++

Shade Of Mine

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.

firefly

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.

ipsec

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.

dot

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...

Shade Of Mine

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.

happystudent

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?

Columbo

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.

happystudent

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?

Columbo

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.

ipsec

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.

Meep Meep

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

audacia

Meep Meep schrieb:

lambdas ohne capturing kannst du als function_pointer verwenden.

Das kannst du mit dem lokalen struct auch. Einfach die Methode statisch machen.

Meep Meep

stimmt. war mir eicht entfallen.
also auch wieder nur zucker

Farbfinsternis

Ich mache das so:

__declspec(property(get = getMyValue, put = setMyValue)) int value;

dann kann ich das einfach verwenden:

myObj->value = 10;
cout << myObj->value; << endl;

hustbaer

@Farbfinsternis
Dir ist schon klar dass das eine Extension von Visual C++ ist, die mit Standard C++ nix zu tun hat?
(Und die mit Standardmitteln auch nicht nachgebildet werden kann.)

Farbfinsternis

Ja, ist mir klar

Torsten Robitzki

Farbfinsternis schrieb:

dann kann ich das einfach verwenden:
myObj->value = 10;
cout << myObj->value; << endl;

Und wo ist da jetzt der Vorteil zu:

cout << myObj->value();

ausser dass der Leser panisch denkt: "SchXXXe: public variables" und das Ganze garantiert nur noch mit bestimmten Compilern übersetzbar ist?

Farbfinsternis

Es wurde nach Properties gefragt und nicht nach Gettern.