Member functions
-
Hallo,
class Screen { public: int someFunction(int a,int b); int someFunctionInline(int a,int b); int someOtherFunction (int a, int b) { return a+b; } private: }; int Screen::someFunction(int a, int b){ return a+b; } inline int Screen::someFunctionInline(int a, int b){ return a+b; }Wie unterscheiden sich diese 3 functions von einander ?
-
Sie haben verschiedene Namen und eine wird nicht kompiliert.
-
someFunctionInline und someOtherFunction sind inline, someFunction nicht. Dir ist bekannt, was inline genau bedeutet? Falls deine Antwort darauf ist "es macht, dass der Compiler den Code direkt einfügt", dann ist diese Antwort unzureichend.
-
SeppJ schrieb:
someFunctionInline und someOtherFunction sind inline, someFunction nicht. Dir ist bekannt, was inline genau bedeutet? Falls deine Antwort darauf ist "es macht, dass der Compiler den Code direkt einfügt", dann ist diese Antwort unzureichend.
Primer ging sehr bescheiden mit den Informationen um. Ich weiß nur das man dem Compiler sagen kann das man eine inline function haben möchte, der compiler entscheidet dann ob er es auch wirklich macht.
Aber den Vorteil habe ich noch nicht so richtig verstanden. Wann sollte man Inline functions verwenden ?
someFunctionInline und someOtherFunction machen anscheinend das selbe. Doch someOtherFunction ist viel weniger schreib arbeit.
Was würde denn passieren wenn der Compiler den Inline Request verweigert ? Würden dann alle functions identisch mit " someFunction " sein ?
-
kantaki schrieb:
Wann sollte man Inline functions verwenden?
Das wird vielleicht klarer, wenn man folgendes beachtet:
- Die ODR (one definition rule). Für inline-Funktionen gelten da andere Regeln als für "normale" Funktionen.
- Ein Compiler allein kann nur Funktionen "inlinen", deren Implementierung er kennt. Deswegen unterscheided die ODR auch zwischen inline und nicht-inline. Du darfst und musst eine inline-Funktionen in jeder Übersetzungseinheit definieren, in der du sie verwenden möchtest, ohne dass das eine Verletzung der ODR darstellt.
- Für "kleine" Funktionen, die oft in "inneren Schleifen" aufgerufen werden und nicht allzuviel tun, ist das interessant, da man ggf den Overhead eines Funktionsaufrufs vermeiden kann und der Compiler die Möglichkeit hat, in diesem Fall über Funktionsgrenzen zu optimieren. Der Preis dafür ist natürlich, dass die Implementierung sichtbar sein muss.
kantaki schrieb:
Was würde denn passieren wenn der Compiler den Inline Request verweigert? Würden dann alle functions identisch mit "someFunction" sein?
Nein. Es sind immer noch "inline-Funktionen", ob sie tatsächlich "geinlinet" werden oder nicht. Das Inlining an sich darf der Compiler verweigern, muss sich aber immer noch an die ODR halten. Ob Inlining wirklich stattfindet oder nicht, macht also, was die Programm-Semantik angeht, überhaupt keinen Unterschied.
Klar soweit?
-
Inline macht:
- Veraltet: Eine Empfehlung, die Funktion als Code am Aufrufort einzusetzen. Heutzutage relativ egal, die Compiler machen was sie für richtig halten, egal ob inline oder nicht.
- Wichtig: Definitionen von Inline-Funktionen dürfen in mehreren Übersetzungseinheiten vorkommen, sofern die Definitionen identisch sind. Dies ermöglichst die Definition von Funktionen im Header. Dies wiederum macht es dem Compiler besonders einfach (oder manchmal überhaupt erst möglich), Funktionen direkt am Aufrufort einzusetzen.
- Noch ein paar Sonderregeln bezüglich der Linkage, die intuitiv klar sein sollten.
-
SeppJ schrieb:
Definitionen von Inline-Funktionen dürfen in mehreren Übersetzungseinheiten vorkommen, sofern die Definitionen identisch sind.
Ja. Wobei ich da noch betonen würde, dass sie es sogar müssen, falls sie in der ÜE verwendet werden.
-
okay danke.
Dh eigentlich :
Inline bei kleinen funktionen , ansonsten nicht inline funktionen benutzen.Ich lese das Inlining nur etwas bei öfteren funktionsaufrufen etwas bringt.
Wie sähe es denn bei Getter / Settern aus ? (falls es so etwas überhaupt in c++ gibt)
Macht es da überhaupt einen unterschied ?
