C++ call by referenz oft verschachteln ok?

[T_55]

Hallo,

wenn man einer Funktion per Referenz Variablen per Struct übergibt dann wird die Speicheradresse weitergegeben soweit gut.

Jetzt zur Frage, wenn man die Referenz aber immer wieder an weitere Unterfunktionen übergibt hat das ab irgend einem Punkt Nachteile? Ich habe gerade ein Fall wo es zu vier Unterfunktionen gekommen ist und habe mich gefragt ob das noch ok ist?

Grüße

 

[Raybeez]

Die größte Gefahr ist, dass du den Überblick verlierst. Da du mit Referenzen arbeitest greift jede Unterfunktion auf das gleiche struct zu. Solange die Zugriffe lesend sind ist das kein Problem. Wenn die Unterfunktionen aber anfangen Daten im struct zu ändern musst du den Überblick behalten, wer gerade was ändert und was das für Auswirkung auf die anderen Funktionen hat

 

[T_55]

Das mit dem Überblick hab ich eigentlich gut im Griff, mein Verständnisproblem ist nur wie das mit den internen Zeigern bei Referenzen funktioniert wenn man die Referenzen immer weiter und weiter gibt. Intern wird ja ein Zeiger benutzt ich frag mich nur wird dann bei jeder Unterfunktion immer wieder der gleiche Zeiger benutzt oder sind das dann Zeiger auf Zeiger...? Und Schlussendlich was dies wiederum für einen Einfluss auf die Performance hat...

 

[Nai]

Es wird der gleiche Zeiger auf die Struct benutzt, nicht aber nicht der selbe; bei jedem Funktionsaufruf wird (wenn man mal Compileroptimierungen vernächlässigt) eine weitere Kopie des Zeigers auf den Stack abgelegt, der auf die Struct zeigt und über die dann das Programm auf die Struct zugreift.

 

[T_55]

Ok danke verstanden, dann sind ein paar Zeigerkopien vermutlich performancemaßig auch nicht so ausschlaggebend. Dann kann ich das so lassen denke ich

 

[Nai]

Auf die Performance sollten sich diese Kopien in der Tat idr kaum auswirken. Ich würde mir an deiner Stelle sowieso als (offensichtlicher) Programmieranfänger keine großen Gedanken um die Performance meiner Programme machen. Denn solche Gedanken lohnen sich nur in den seltensten Fällen.

 

[GregoryH]

Faustregel ist, Basistypen (int, float, etc, <= sizeof(void*)) kann man als Kopie übergeben. Größere Structs wenn möglich als const-reference oder als Pointer. Mit Compileroptimierungen ist der Overhead von const auto& vernachlässigbar, vor allem im Vergleich zu Kopien.

@Nai
Da muss ich widersprechen! So einfache Sachen lohnen sich von Anfang an. Die Programme wachsen im Laufe der Zeit und wenn man sich direkt angewöhnt größere Structs als const auto& zu übergeben ist das nur von Vorteil!

Positiv ist auch, man lernt sich Gedanken über die const correctness zu machen.

Noch extremer wird es in Sprachen wie Rust, bei denen man sich direkt bei Deklaration der Variable überlegen muss ob sie mutable sein soll oder nicht.

 

[antred]

Noch extremer wird es in Sprachen wie Rust, bei denen man sich direkt bei Deklaration der Variable überlegen muss ob sie mutable sein soll oder nicht.

Ohne mich bisher mit Rust auseinandergesetzt zu haben, das muß man doch aber bei C++ auch ... also sich entscheiden, ob ein Objekt const oder nicht sein soll. Oder wie war das gemeint?

 

[The Ripper]

In Rust sind variablen by default const (immutable). Das heißt, man muss sie erst variabel (muteable) machen. In C++ ist es wie in den meisten anderen Sprachen genau umgedreht.

 

[GregoryH]

Genau. Zusätzlich kannst du auf ein mutable variable auch nur eine einzige mutable reference haben (oder unlimitert viele immutable references), etc, macht einige Dinge umständlicher aber die Sprache auch deutlich "sicherer" als C++.