ihr ich hab ein Array und möchte da zugreifen nun gibt es eine entscheidungsproblem:

1. Get/Set elengater und Information-Hiding vorteil aber evtl langsam (oder?)
2. direkt zugriff auf puplic Member schneller (oder?)

grüße

MyArray const& daten = objekt.GetDaten();
/* ... */ daten[i] /* ... */ daten[i+1] /* ... */ daten[i-1] /* ... */

im Vergleich zu

/* ... */ objekt.GetDaten()[i] /* ... */ objekt.GetDaten()[i+1] /* ... */ objekt.GetDaten()[i-1] /* ... */

In einer Schleife, in der nur pro Durchlauf einmal auf das Array zugegriffen wird, ist das natürlich weniger optisch hilfreich als vielmehr zur Reduzierung Deiner (unbegründeten, wenn inline) Performance-Sorge.

Ist der Code jedoch zu langsam, schaue ich genau, was den Code langsam macht. Vllt. sind es die Funktionsaufrufe, vllt. ist es die Datenstruktur, vllt. nur eine bestimmte Operation auf die Datenstruktur, vllt. ist aber auch der Algo scheiße.
Wenn ich dann weiß, was genau bremst, kann ich anfangen Optimierungen durchzuführen, die wirklich einen Effekt haben.

Wir wissen ja, was Hoare zu dem Thema sagt: "Der frühe Vogel fängt den Wurm" ... äh, na ja. Eigentlich: "Zu frühe Optimierung ist die Wurzel allen Übels."

Eine Getter darf aber auch keine Referenzen oder Zeiger (ausser const) auf interne Strukturen liefern. Ein Zeiger auf ein Array zu liefern (auch ein const-Zeiger) verbietet sich, da dieses eine bestimmte Implementierung voraussetzen würde.

Inline Getter sind genauso schnell, wie direkte Zugriffe. Selbst wenn ich im Getter noch z. B. eine Index-Variable mitgebe, optimiert der Compiler das raus.

Benötige ich das gesamte Array zur Verarbeitung, ist zu überlegen, ob die Verarbeitungsmethode nicht in die Klasse selbst gehört.

Es gibt nur sehr selten in C++ den Bedarf, aus Performancegründen etwas unsauber zu implementieren. Genau dafür schätze ich C++.

Tntnet

Warum schreibt ihr eigentlich immer was von inline?

Ich nahm an, dass die Methode im Header gleich definiert wurde, ergo implizit inline. :xmas1:

Warum schreibt ihr eigentlich immer was von inline? Jeder vernünftige Compiler sollte so schlau sein, und Member-Funktionen die nur ein return x oder x = y haben, autom. inline machen. Darueber mache ich mir absolut keine Gedanke. Muesste ich dieses tun, wuerde ich meinen Compiler wegschmeissen!!!

Sollte (und meistens entscheidet der Compiler sowieso selber, was er inlinet)
Aber es gibt Situationen, wo selbst ein einfaches "return irgendwas" nicht mehr inline aufgelöst werden kann (z.B. bei virtuellen Funktionen oder wenn du die Definiton in eine eigene Übersetzungseinheit auslagerst), deshalb sollte man solche Getter/Setter schon inline-tauglich anlegen.

@GPC; Der Code ist schon voll Funktionfähig... jetzt wo das Programm fertig ist .. mach ich mir noch bischen gedanken über optimierungen... Grüße

Falscher Ansatz. Keine "Gedanken" über Optimierung machen, sondern:

- Profiler laufen lassen
- Bottlenecks identifizieren.
- diese dann gezielt optmieren
- Mit Profiler prüfen ob die Optimierung auch gegriffen hat (vorher/nachher vergleich)

Alles andere fällt unter den Begriff "premature optimizing".

Artchi schrieb:

Warum schreibt ihr eigentlich immer was von inline? Jeder vernünftige Compiler sollte so schlau sein, und Member-Funktionen die nur ein return x oder x = y haben, autom. inline machen. Darueber mache ich mir absolut keine Gedanke. Muesste ich dieses tun, wuerde ich meinen Compiler wegschmeissen!!!

Sollte (und meistens entscheidet der Compiler sowieso selber, was er inlinet)
Aber es gibt Situationen, wo selbst ein einfaches "return irgendwas" nicht mehr inline aufgelöst werden kann (z.B. bei virtuellen Funktionen oder wenn du die Definiton in eine eigene Übersetzungseinheit auslagerst), deshalb sollte man solche Getter/Setter schon inline-tauglich anlegen.

Dem möchte ich mich anschliessen. Ich verwende fast nie das Wort "inline", sondern achte darauf, wie ich meine Methoden schreibe, damit der Compiler eine Chance hat, das zu optimieren. "inline-tauglich" ist das richtige Stichwort. Die Implementieriung einfacher Getter oder Setter gehören in den Header. Damit gebe ich dem Compiler die Informationen, die er benötigt. Man sollte das durchaus im Hinterkopf behalten, wenn man Code schreibt.

Aber wirklich nur im Hinterkopf. Nicht das aus so einer Nebensache dann die Hauptsache wird. Beim Programmieren sollte man sich in erster Linie auf das Problem konzentrieren und nicht auf die Optimierung.

Tntnet