Stilfrage: T& a oder T &a

[knivil]

Wenn er mir nicht zustimmt, dass es streng genommen nicht stimmt, dann hab ich keine Gründe, das zu tun.

Wenn du also nicht seiner Meinung bist, dann willst du nicht mit ihm reden. Aber wenn du seiner Meinung bist, dann gibt es keinen Grund fuer eine Diskussion. Ergo: In beiden Faellen wirst du nicht mit ihm reden. Deine Argumentation ist echt Bullshit.

Ansonsten: Wie unterscheidet sich eine Referenz auf ein Objekt vom eigentlichen Objekt? Und was ist dann eine Referenz von einer Referenz? Und warum sollte der Typkonstruktor & sich bei Anwendung auf Objekten anders verhalten als bei Referenzen? Warum kann ich dann Referenzen nicht neu zuweisen? Rein logisch gesehen gibt es Probleme, wenn Objekt und Referenz semantisch verschieden ist.

[Columbo]

knivil schrieb:

Wenn er mir nicht zustimmt, dass es streng genommen nicht stimmt, dann hab ich keine Gründe, das zu tun.

Wenn du also nicht seiner Meinung bist, dann willst du nicht mit ihm reden. Aber wenn du seiner Meinung bist, dann gibt es keinen Grund fuer eine Diskussion. Ergo: In beiden Faellen wirst du nicht mit ihm reden. Deine Argumentation ist echt Bullshit.

Gut, nicht mit ihm zu diskutieren ist keine Lösung. Wenn er tatsächlich der Überzeugung ist, das Referenzen völlig äquivalent zum Objekt sind, dann würde ich ihn gerne in einer Diskussion anders stimmen. Besser?

Ansonsten: Wie unterscheidet sich eine Referenz auf ein Objekt vom eigentlichen Objekt?

Die Referenz kann ungültig werden. Ein Objekt kann es nicht. Die Größe einer Referenz ist nicht einheitlich. Die des Objektes schon.

struct A
{
    std::string& str;
};
// Was ist sizeof(A)? Was ist die Summe der Größen der Member? Wäre das anders, wenn du stattdessen einen std::string als Member hast?

Und was ist dann eine Referenz von einer Referenz?

Gibt es nicht, ist mMn. auch Schwachsinn.

Und warum sollte der Typkonstruktor & sich bei Anwendung auf Objekten anders verhalten als bei Referenzen?

Weil du das && schon für eine rvalue-Referenz brauchst.

Warum kann ich dann Referenzen nicht neu zuweisen?

Weil es AFAICS keinen vernünftigen Weg gibt, das syntaktisch zu symbolisieren. Die Referenz soll ja ein neuer Name für ein Objekt sein, und sich von diesem praktisch nicht mehr unterscheiden lassen.

Rein logisch gesehen gibt es Probleme, wenn Objekt und Referenz semantisch verschieden ist.

Da gebe ich dir Recht, sie sollten sich semantisch völlig gleich verhalten.

Der einzige, der hier "terminologisches Gerede" provoziert, bist du.

Kann gut sein. Einer ist es zumindest. Was mich bei dem Post gestört hat, ist lediglich, dass Referenzen nicht einfach irgendwelche Werte sind, die kopiert werden, und das call-by-reference einfach eine Bezeichnung für Referenzen als Parameter ist.

[knivil]

keinen vernünftigen Weg gibt, das syntaktisch zu symbolisieren

Doch gibt es. Aber du klebst zu sehr an Syntax und Implementation. Referenz von Referenz kann gern durch & & repraesentiert werden. Bitte nicht mit && verwechseln. Weiterhin existieren Referenzen schon vor C++11, d.h. && als Argument ist Schwachsinn.

Gibt es nicht, ist mMn. auch Schwachsinn.

Doch gibt es. Es ist nur nicht das, was du denkst.

Die Referenz kann ungültig werden.

Wie unterscheidet sich das von UB?

[Bitte ein Bit]

Wo ich gerade bei nutzloser Semantiknerverei bin: In C++ gibt es nur call by value. Call by reference gibts weder in C noch in C++ noch in Java.

Alles nur wegen einer solchen Pimserei.

Ja wenn es doch nur Call-By-Value gibt, wieso hat dann mein Code soviele Seiteneffekte, wo doch Call-By-Value Seiteneffekt-Freiheit verspricht? Und wieso ist mein Code so unperformant?

void Test(string T, int& a)
{
  // Müll
  a++;
}

int main(int argc, char** arv)
{
  string Dump = "";
  int a;

  for (size_t i = 0; i < 1E5; i++)
    Dump += "d";
  for (size_t j = 0; j < 1E5; j++)
    Test(Dump, a);
}

An Call-by-Value kann es ja nicht liegen...

Völlig falsches Abstraktionsniveau.

[Bashar]

Bitte ein Bit schrieb:

Ja wenn es doch nur Call-By-Value gibt, wieso hat dann mein Code soviele Seiteneffekte, wo doch Call-By-Value Seiteneffekt-Freiheit verspricht?

Tut es nicht. Frage beantwortet?

[nwp3]

Bitte ein Bit schrieb:

Ja wenn es doch nur Call-By-Value gibt, wieso hat dann mein Code soviele Seiteneffekte, wo doch Call-By-Value Seiteneffekt-Freiheit verspricht?

Weil es das nur für den übergebenen Wert verspricht, nicht für Werte, die der übergebene Wert referenziert.

[Bitte ein Bit]

Frage beantwortet?

Ja natürlich.

Ich finde es halt nur ein wenig amüsant, wie diese Aussage einen solchen Datenwust verursachen konnte. Ich habe mir bildlich einen DAU vorgestellt, der die Aussagen "es gibt nur Call-By-Value" missversteht und dann eine Blödzinn wie in meinem letzten Beitrag verzapft.

[Bitte ein Bit]

Weil es das nur für den übergebenen Wert verspricht, nicht für Werte, die der übergebene Wert referenziert.

Weil du sagst, dass Referenzen mittels Pointern implementiert werden, welche mittles Call-By-Value übergeben werden.

Richtig?

[nwp3]

Die Referenz wird by value übergeben. Wie die implementiert ist ist unerheblich.

[Bitte ein Bit]

Die Referenz wird by value übergeben. Wie die implementiert ist ist unerheblich.

Von hinten durch die Burst,
und das mit inniger Lust...

Sehe ich bei der Verwendung von Referenzen dieses Detail? Das die Referenz-Klasse/Datenobjekt/Zeiger/Apfelkuchen als Call-By-Value übergeben wird?

Nö.

Also kann ich etwas abstrahieren und sagen das ist Call-By-Reference. Sonst würden Referenzen nicht Referenzen heißen.

Und selbst der geneigte Entwickler kann bei Zeigern mit ein wenig Abstraktionsvermögen unter gewissen Umständen Call-By-Reference entdecken.

[nwp3]

Bitte ein Bit schrieb:

Also kann ich etwas abstrahieren und sagen das ist Call-By-Reference. Sonst würden Referenzen nicht Referenzen heißen.

Und selbst der geneigte Entwickler kann bei Zeigern mit ein wenig Abstraktionsvermögen unter gewissen Umständen Call-By-Reference entdecken.

Kann man tun. Sollte man aber nicht. Denn das ist viel komplizierter als die call by value Sicht und außerdem nicht eindeutig.
"Ich übergebe eine Referenz auf einen String" ist für mich eindeutig. Nur String & ist möglich. Bei dir geht String &, String *, String **, ... als "Referenz" durch.

Ich lass das jetzt mal sein, bringt eh nichts.

[otze]

nwp3 schrieb:

Das Rausoptimieren ist doch kein Argument, das passiert bei Pointern und Integern auch.

void myFunc(int& a){
   ...
   myFunc(a);//call by value?
}

angenommen der Compiler optimiert den Funktionsaufruf nicht raus:wärst du dir sicher, dass hier das "referenzobjekt" im inneren kopiert wird? Oder könnte der Compiler das nicht doch anders smart machen?

[camper]

Ich bin etwas überrascht, wer sich alles an der Diskussion beteiligt.

[Nathan]

Aber eigentlich hat nwp3 Recht:
Bei call by reference wird eine reference by value übergeben, also ist das eigemtlich call by value.

[Ze Klauwn]

Nathan schrieb:

Aber eigentlich hat nwp3 Recht:
Bei call by reference wird eine reference by value übergeben, also ist das eigemtlich call by value.

"Aber eigentlich hat nwp3 Unrecht:
Bei call by reference wird ein object by reference übergeben, also ist das eigemtlich call by reference."

Echt lustig, die Argumentation hier, nur um krampfhaft der geläufigen Terminologie zu widersprechen

[Nathan]

Ich sag ja auch, dass call by reference call by reference ist.
Aber:
template <typename T> void func(T t);
Ist eindeutig call by value.
Und
func<int&>(foo);
ist folglich ebenfalls call by value aus Sicht der Funktion, aber call by reference aus Sicht des Aufrufers.
Denn T - also int& - wird ja by value übergeben, aber foo wird by reference übergeben.

[Ze Klauwn]

Nathan schrieb:

template <typename T> void func(T t);
Ist eindeutig call by value.

Nein. Was es ist, hängt von T ab.

Mir ist durchaus klar, worauf du hinauswillst. Natürlich kann man die Sichtweise vertreten, die Referenz werde kopiert. Das ändert aber nichts an der Definition (!) von "call-by-reference" als Übergabe einer "Indirektion" auf ein Objekt anstelle des Objekts selbst. Der Begriff stammt ja ursprünglich auch aus Sprachen, wo die Unterscheidung klarer ist als in C++.

Alle Übergaben als "call-by-value" zu bezeichnen, widerspricht nicht nur der Definition und dem weitläufigen Verständnis des Begriffs, sondern macht letzteren komplett überflüssig. Wenn du nicht mehr unterscheidest, haben die Begriffe Null Aussagekraft.

[Nathan]

Ich schrieb ja selber:

Nathan schrieb:

Ich sag ja auch, dass call by reference call by reference ist.

[Columbo]

Nathan schrieb:

Ich sag ja auch, dass call by reference call by reference ist.

Schön, dass wir diese Tautologie geklärt haben.

Alle Übergaben als "call-by-value" zu bezeichnen, widerspricht nicht nur der Definition und dem weitläufigen Verständnis des Begriffs, sondern macht letzteren komplett überflüssig. Wenn du nicht mehr unterscheidest, haben die Begriffe Null Aussagekraft.

Danke, so meinte ich das.

[Bitte ein Bit]

Aber eigentlich hat nwp3 Recht:
Bei call by reference wird eine reference by value übergeben, also ist das eigemtlich call by value.

Und programmiertechnisch hat er Unrecht.

void Test(int& a) {}

Ja intern, da wird bei auch bei Call-By-Reference was übergeben. Wir reden davon das die compilertechnische Implementierung des & Operators evt. auch per Call_By-Value übergeben werden könnte!

Aber das juckt mich doch beim Programmieren nicht!

Call-By-Value und Call-By-Reference sind doch ein Hilfsmittel beim erlernen einer Programmiersprache. Call-By-Reference sagt, dass ich ein abstrakten Datentyp (ADT) mittels einer Referenz ansprechen möchte, und nicht in dem ich das komplette Objekt kopiere.