Stilfrage: T& a oder T &a

[unqualified user]

Sone schrieb:

Wende ich den Adressoperator an, dann bekomme ich eine Adresse.

Kannst du diese dummen Binsenweisheiten lassen? Eine Referenz hat keine Adresse, das ist ganz klar und unumstritten.

Kannst du diese dummen Binsenweisheiten lassen? Eine "Referenz" ist vielleicht kein Objekt, aber sie hat ganz sicher eine Adresse.

[Columbo]

unqualified user schrieb:

Kannst du diese dummen Binsenweisheiten lassen?

Wäre es eine Binsenwahrheit, wäre sie zumindest einmal wahr (das ist meine Aussage ohnehin). Aber du bestreitest es gar im nächsten Satz:

Eine "Referenz" ist vielleicht kein Objekt, aber sie hat ganz sicher eine Adresse.

Nein! Aber wieso sage ich das zum x-ten mal?

[otze]

unqualified user schrieb:

Kannst du diese dummen Binsenweisheiten lassen? Eine "Referenz" ist vielleicht kein Objekt, aber sie hat ganz sicher eine Adresse.

Ausser sie wird rausoptimiert. Oder der Compiler ist anderweitig schlau indem er das Objekt direkt an der richtigen Stelle im Stack konstruiert hat.

[Kellerautomat]

knivil schrieb:

* und & sind Typkonstruktoren, d.h. angewendet auf einen Typen liefern sie als Ergebnis wieder einen Typen. Sie sind nicht Teil des Namens. Da hilft es auch nicht, mit "bad practise" zu argumentieren, auch wenn es die Syntax erlaubt:

T* a, b;

Persoenlich meide ich das.

Schoen, dass wenigstens einer hier funktional programmiert und die Konzepte verstanden hat.

Zu Mehrfachdefinitionen: Absolut kein Problem:

int* p, * q;

[knivil]

Eine Referenz hat keine Adresse, das ist ganz klar und unumstritten.

Nun, es gibt nicht umsonst FAQs. was ist so schwer an:

It is the object.

[Columbo]

Various features of the language, such as references and virtual functions, might involve additional memory locations that are not accessible to programs but are managed by the implementation.

Ihr meint also, dass die Implementierung der Referenz für diese Speicher belegt, welcher dann ein erstes Byte hat, wessen Adresse man dann mit der Adresse der Referenz gleichsetzen kann? Tja, das wäre sehr vage.

Edit: Und man sollte nicht die Adresse der Referenz mit der Adresse des Objektes gleichsetzen. Die Adresse, die der Adressoperator da zurückgibt, ist immer die Adresse des referenzierten Objektes.

[knivil]

Edit: Und man sollte nicht die Adresse der Referenz mit der Adresse des Objektes gleichsetzen. Die Adresse, die der Adressoperator da zurückgibt, ist immer die Adresse des referenzierten Objektes.

Du hast immer noch nicht verstanden. Eine Referenz ist nicht vom eigentlichen Objekt unterscheidbar:

It is the object.

PS: Diskutiere doch mit dem Autor des FAQs weiter.

[nwp3]

Das Rausoptimieren ist doch kein Argument, das passiert bei Pointern und Integern auch.
Ich verstehe auch nicht was mit "Man übergibt ein lvalue an die Funktion" gemeint ist. Kann doch auch ein rvalue sein. Ist auch völlig egal.*

call-by-reference heißt meine Meinung nach "du übergibst einen Verweis auf ein Objekt, welches dann in einem fremden Code verändert wird."

Der Knackpunkt ist wer es tut. Ist es in der Sprache definiert, dass bei Übergabe eines Objektes tatsächlich eine Referenz übergeben wird oder wird das Objekt kopiert? Selber eine Referenz anlegen und übergeben ist kein call by reference.

Referenzen belegen natürlich Speicher, der festlegt, auf welches Objekt sich die Referenz bezieht. Genauso wie der Mechanismus hinter virtuellen Funktionen, der entscheidet, welche Funktion tatsächlich aufgerufen wird. Und genauso wie bei Referenzen kommt man nicht standardkonform an diesen Speicher. Was das Ganze mit "ist eine Referenz ein Objekt?" zu tun hat entgeht mir auch. Reine Auslegungs-/Definitions-sache ohne Konsequenzen. Aber gut, das ist call by reference vs call by value auch :p

*~@Sone: Hier kannst du sehen wie man die Leute nicht mit "Du schreibst völligen Unfug" anpisst.~

[Columbo]

Referenzen belegen natürlich Speicher

Woher weißt du das?

Ich verstehe auch nicht was mit "Man übergibt ein lvalue an die Funktion" gemeint ist.

Man übergibt an die Funktion einen Ausdruck. Ausdrücke werden bekanntlich unterteilt in lvalues und rvalues.

Selber eine Referenz anlegen und übergeben ist kein call by reference.

Wieso nicht?

Was das Ganze mit "ist eine Referenz ein Objekt?" zu tun hat entgeht mir auch.

Mir auch. Mittlerweile geht es lediglich um die Adresse.

Diskutiere doch mit dem Autor des FAQs weiter.

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

Hier kannst du sehen wie man die Leute nicht mit "Du schreibst völligen Unfug" anpisst.

Es tut mir Leid. Aber call-by-reference gibt es in C++, und wer etwas anderes behauptet der provoziert nur terminologisches Gerede.

[Kellerautomat]

Arcoth schrieb:

Es tut mir Leid. Aber call-by-reference gibt es in C++, und wer etwas anderes behauptet der provoziert nur terminologisches Gerede.

Der einzige, der hier "terminologisches Gerede" provoziert, bist du. Du bist derjenige, der andauernd mit Standard-Quotes klugscheisst.
In der realen Welt interessiert sich niemand fuer den idealisierten C++-Standard. Dort brauchen Referenzen naemlich Speicher, wenn sie nicht wegoptimiert werden, weil sie naemlich Zeiger sind.

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