inline int function1 (const int  a, const int  b) { return a+b; }
inline int funktion2 (const int &a, const int &b) { return a+b; }

Wie wird das dann in einem solchen Gefüge übersetzt?

int a,b;
cout<<functionX(a, b);

Werden in Funktion 1 die beiden int Werte in temporäre ints kopiert und dann ausgewertet? Und werden in Funktion 2 immer noch Referenzen von a und b übergeben und mit den Referenzen agiert oder werden die Objekte direkt verwendet?

inline void funktion1 ( int  a ) { ++a; }
inline void funkiton2 ( int& a ) { ++a; }

Im erste Fall muss der Compiler ja eine temporäre Variable anlegen, da ja nur die Kopie von a verändert wird. Im zweiten Fall wird a über die Referenz geändert. Wird der Compiler dann im 2. Fall einfach a einfügen oder auch mit der Referenz arbeiten?

inline void () {}

richtig... das gleiche, wie bei der fkt., wo der parameter per value übergeben wird - er optimiert sie weg...
beim zweiten steht dann iwann ma nen ++x im quellcode, japp...

bb

ps: und trotzdem könntest du dir den erzeugten (asm-)code aus dem eingangspost ma angucken - er ist gleich...

Eine inline expandierte Funktion verhält sich in allen Belangen wie eine normale Funktion.

Wobei das Schlüsselwort inline keine Garantie abgibt, dass die Funktion auch inline expandiert wird.

@inliner,
Sowas ist völlig vom Kompiler abhängig, da ist es schwer etwas auszusagen. Kann sein dass alles völlig wegoptimiert wird und am Ende gar nicht mehr vorhanden ist.
Gerade bei deinem zweiten Beispiel könnte es gut sein, dass die erste Methode ganz verschwindet. Und die zweite Methode einfach wegfällt und die Variable direkt inkrementiert wird. Aber das hängt wie gesagt, ganz vom Kompiler und seinen Optimierungen ab.

Grüssli

Gerade bei deinem zweiten Beispiel könnte es gut sein, dass die erste Methode ganz verschwindet. Und die zweite Methode einfach wegfällt und die Variable direkt inkrementiert wird. Aber das hängt wie gesagt, ganz vom Kompiler und seinen Optimierungen ab.

Es hängt zwar vom Compiler ab, aber meinst du wirklich, dass es noch Compiler gibt, die nicht fähig sind, so zu optimieren? Oo

bb

Es hängt zwar vom Compiler ab, aber meinst du wirklich, dass es noch Compiler gibt, die nicht fähig sind, so zu optimieren? Oo

1. Weisst du eigentlich, wieviele Kompiler es gibt? Für irgendwelche seltsamen Platformen?
2. Weisst du eigentlich, wieviele von diesen Dinger völliger Scheiss sind?

Ich hatte erst gerade vor einem halben Jahr mit so einem blöden und seltsamen C (bzw. ein Dialekt von C) Kompiler zu tun.

3. Die Frage ist aber auch, wie optimiert wird. Das hängt noch vom ganzen Rest ab. Kann sein dass da viel mehr optimiert wird, als nur diese Funktion. Und wie dies dann optimiert wird, da kann man nur raten. Es geht also nicht darum, dass er das nicht schafft, sondern das er noch viel besser ist als das

Grüssli