 |
C++Talk.NET C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Markus Schaaf Guest
|
Posted: Thu Nov 20, 2003 2:38 pm Post subject: Re: Compiler-Optimierung von const-membern? |
|
|
Gerrit Einhoff schrieb:
| Quote: | const std::map<B, C> myMap() const {return meineMap;}
Frage: Ich habe mich mehr oder weniger darauf verlassen, dass der Compiler
(gcc) wegen der const-Deklaration den call-by-value myMap() wegoptimiert.
|
Das geht nicht.
| Quote: | Ist diese Annahme überhaupt korrekt? Oder wird bei jedem Aufruf die
komplette Map kopiert?
|
Inklusive aller Elemente, ja.
| Quote: | Hat es Vorteile die Funktion zu
const std::map<B, C>* myMap() const {return &meineMap;}
umzudefinieren?
|
Gegenüber dem da oben, ja.
| Quote: | Oder bringt die zusätzliche Pointer-Dereferenzierung (z.B.
a->myMap()->begin()) wieder Performancenachteile?
|
Im Vergleich wozu? Dem Kopieren der gesamten Map? Die Frage ist nicht
Dein Ernst.
| Quote: | Gibt es für solche
Accessor-methoden generelle bevorzugte Vorgehensweisen?
|
Referenzen.
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
 |
Albrecht Fritzsche Guest
|
Posted: Thu Nov 20, 2003 2:40 pm Post subject: Re: Compiler-Optimierung von const-membern? |
|
|
Gerrit Einhoff wrote:
| Quote: | Hallo.
Ich habe folgende Klasse:
class A {
std::map<B, C> meineMap;
public:
const std::map<B, C> myMap() const {return meineMap;}
|
Warum nicht eher
const std::map<B,C>& myMap() const ...
Ali
--
albrecht fritzsche
ableton, schönhauser allee 6/7
10119 berlin germany
http://www.ableton.com
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
 |
André Pönitz Guest
|
Posted: Thu Nov 20, 2003 2:46 pm Post subject: Re: Compiler-Optimierung von const-membern? |
|
|
Gerrit Einhoff <gerein (AT) gmx (DOT) de> wrote:
| Quote: | Hallo.
Ich habe folgende Klasse:
class A {
std::map<B, C> meineMap;
public:
const std::map<B, C> myMap() const {return meineMap;}
};
Im späteren Code wird der myMap()-Accessor relativ häufig gebraucht, z.b. in
Iterator-Schleifen wie:
for (map<B, C>::const_iterator i = a->myMap().begin(); i !=
a->myMap().end(); i++) {...}
Frage: Ich habe mich mehr oder weniger darauf verlassen, dass der Compiler
(gcc) wegen der const-Deklaration den call-by-value myMap() wegoptimiert.
|
Es gibt keinen Grund das anzunehmen solange Du das nicht im produzierten
Assembler "gesehen" hast.
| Quote: | Ist diese Annahme überhaupt korrekt?
|
Der Compiler kann nicht zu einer solchen Optimierung gezwungen werden.
Im guenstigsten Falle fuer Dich macht das zwar Dein derzeitiger gcc,
aber die Annahme ist 'unportabel', d.h. gilt nicht fuer den naechsten
Compiler.
| Quote: | Oder wird bei jedem Aufruf die
komplette Map kopiert?
Hat es Vorteile die Funktion zu
const std::map<B, C>* myMap() const {return &meineMap;}
umzudefinieren? Oder bringt die zusätzliche Pointer-Dereferenzierung (z.B.
a->myMap()->begin()) wieder Performancenachteile?
|
Duerfte im Vergleich zur Kopie zu vernachlaessigen sein. Warum
eigentlich Zeiger und keine Referenz?
Im uebrigen koenntest Du den a->myMap().end()-Aufruf aus der Schleife
rausziehen (zumindest mit in den 'Deklarationsteil'). Das spart Dir
schon mal n-1 von n+1 Aufrufen von a-myMap().
| Quote: | Gibt es für solche Accessor-methoden generelle bevorzugte
Vorgehensweisen?
|
Naja, es ist nicht vollkommen unueblich, die 'begin' und
'end'-Iteratoren, nicht aber die gesamte map rauszureichen.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|