return in Listeninitialisierer

[Markus (Gast)]

Wozu dienen hier die zwei Zeilen mit dem return A() ?

#include <iostream>

class A {
public:
    void foo() const { std::cout << "A::foo() const\n"; }
    void foo() { std::cout << "A::foo()\n"; }
};

A bar() { return A(); }
const A cbar() { return A(); }


int main()
{
    bar().foo();  // calls foo
    cbar().foo(); // calls foo const
}

Warum nicht so?

#include <iostream>

class A {
public:
    void foo() const { std::cout << "A::foo() const\n"; }
    void foo() { std::cout << "A::foo()\n"; }
};


int main()
{
    A bar;
    const A cbar;

    bar.foo();  // calls foo
    cbar.foo(); // calls foo const
}

(eigentlich dient der Code zur Veranschaulichung CV-qualifizierter 
r-values)

[Oliver S. (oliverso)]

Markus schrieb:
> Warum nicht so?

Der erste Fall ruft foo über Funktionen (const/nicht const) auf, deine 
Lösung dagegen über Variablen (const/nicht const).

Auch wenn es ähnliche aussieht, ist das nicht das selbe. Das const 
steckt da an verschiedenen Stellen.

Ob das für den Demonstrations- und Lerneffekt wichtig ist, keine Ahnung. 
Da fehlt der Kontext des Beispiels.

Oliver

[MaWin (Gast)]

Hoffentlich steht bei dem Beispiel auch fett dabei:

Mach das nicht!

Denn const und nicht-const zu überladen, ist sehr verwirrend. Da blickt 
am Ende niemand mehr durch.

[Oliver S. (oliverso)]

MaWin schrieb:
> Denn const und nicht-const zu überladen, ist sehr verwirrend. Da blickt
> am Ende niemand mehr durch.

Das ist leider eine der Ecken in C++, erforderlich sind, aber kaum schön 
gelöst werden können.

Oliver

[Markus (Gast)]

Oliver S. schrieb:
> Der erste Fall ruft foo über Funktionen (const/nicht const) auf, deine
> Lösung dagegen über Variablen (const/nicht const).

Ähhhh, jetzt wo du es sagst....
Ich hatte die Klammern übersehen und es so gelesen, daß ein Objekt bar 
der Klasse A angelegt wird.

[Wilhelm M. (wimalopaan)]

Was hat das Thema mit Listen zu tun?

Meinst Du wirklich die Unterscheidung ro/rw bei return-Werten?

Oder meinst Du die ref-Qualifikation von Elementfunktion? Also, ob eine 
Elementfunktion auf ein rvalue oder lvalue anwendbar ist (ich meine 
nicht die Parameterliste).

Ersteres ist bei primitiven DT sinnlos und bei UDT ggf. schlecht, weil 
es ein move ggf. verhindert.

[Markus (Gast)]

Wilhelm M. schrieb:
> Was hat das Thema mit Listen zu tun?

Gar nichts, ich wußte nicht, welcher Titel am besten paßt: Anstatt

A bar() { return A(); }

 las ich

A bar { return A(); }

 und wunderte mich über das { return A(); }. Wie nennst du hier die 
geschweiften Klammern?
Mit dem eigentlichen Thema des Beispiels hat meine Frage gar nichts zu 
tun, denn:

> Meinst Du wirklich die Unterscheidung ro/rw bei return-Werten?

Darauf läuft es im Buch hinaus, Überladen von const und nicht-const.
Zuvor muß ich aber lvalues und rvalues verstehen...


> Oder meinst Du die ref-Qualifikation von Elementfunktion? Also, ob eine
> Elementfunktion auf ein rvalue oder lvalue anwendbar ist (ich meine
> nicht die Parameterliste).
> Ersteres ist bei primitiven DT sinnlos und bei UDT ggf. schlecht, weil
> es ein move ggf. verhindert.

Was immer damit gemeint sein mag, ich bin davon noch weit entfernt ;-)

[Wilhelm M. (wimalopaan)]

Markus schrieb:
> Wilhelm M. schrieb:
>> Was hat das Thema mit Listen zu tun?
>
> Gar nichts, ich wußte nicht, welcher Titel am besten paßt:

Dann wundere Dich nicht über wenige Beiträge zum eigentlichen Thema ;-)

> Anstatt

A 
> bar() { return A(); }

 las ich

A bar { return A(); }

 und
> wunderte mich über das { return A(); }. Wie nennst du hier die
> geschweiften Klammern?

Der Funktionskörper ist ein Block: die geschweiften Klammen sind die 
Block-Begrenzer.

>> Meinst Du wirklich die Unterscheidung ro/rw bei return-Werten?
>
> Darauf läuft es im Buch hinaus, Überladen von const und nicht-const.

Bzgl. des Rückgabetyps kannst Du in C++ nicht überladen: der Typ der 
Funktion ist nicht Bestandteil der Signatur, deswegen ist solches 
Vorgehen kein korrektes Überladen.

Von Überladen spricht man, wenn die Signatur sich unterscheidet, aber 
der Name (Bestandteil der Signatur) gleich bleibt:

void f();
void f(int);

oder

struct A {
   voif f();
   voif f() const;
};

> Zuvor muß ich aber lvalues und rvalues verstehen...

Betrachte rvalues als temporäre-anonyme Objekte.

>> Oder meinst Du die ref-Qualifikation von Elementfunktion? Also, ob eine
>> Elementfunktion auf ein rvalue oder lvalue anwendbar ist (ich meine
>> nicht die Parameterliste).
>> Ersteres ist bei primitiven DT sinnlos und bei UDT ggf. schlecht, weil
>> es ein move ggf. verhindert.
>
> Was immer damit gemeint sein mag, ich bin davon noch weit entfernt ;-)

Ok, dann vergiss es fürs erste. Es geht um:

struct A {
    void f() &; 
    void f() &&;
};

A foo();

Im ersten Fall muss das Objekt, für dass f() aufgerufen wird (bspw: 
a.f()) ein lvalue sein, im zweiten Fall ein rvalue (bspw: foo().f() ).

[mikro77 (Gast)]

Ich weiß nicht was sich der Autor dabei gedacht hat:

Markus schrieb:

const A cbar() { return A(); }

Const für einen Rückgabewert auf ein Value (also keine Referenz/Pointer) 
macht keinen Sinn. Zumindest ist mir kein Fall bekannt und ich habe noch 
von keinem Fall gelesen, wo es sinnvoll ist. Außer natürlich wie hier um 
clever zu demonstrieren wann nicht/const Funktionen aufgerufen werden. 
/Ironie

Z.B. 
https://www.sandordargo.com/blog/2020/11/18/when-use-const-3-return-types

Aber selbst Scott Meyers war damals drauf reingefallen (in seinem Buch) 
und hat es erst später korrigiert. ;-)

[Markus (Gast)]

Das Codefragment stammt aus:

https://eli.thegreenplace.net/2011/12/15/understanding-lvalues-and-rvalues-in-c-and-c