Wann inline benutzen?
-
man lernt doch nie aus.
-
Bashar schrieb:
Da hat die FAQ anscheinend Nachholbedarf. Gibts da schon einen passenden Text zu, oder soll ich einen schreiben?
Wäre schön wenn du was dazu schreibst.
Ich habe hier zwar auch noch einen 7-Seiten Draft-Text zum Thema rumliegen, aber der wird sowieso nie fertig (liegt schon seit fast einem Jahr auf meiner Festplatte rum).
-
Facer schrieb:
das heisst alles was klein und fein ist und vor allem oft gebraucht wird wird inline gemacht
war's nicht so dass der compiler stillschweigend nicht 'inlined' wenn's ihm nicht in den kram passt? man kann auch ein #define nehmen. das wird immer 'ge-inlined'. templates ja auch.
-
Wenn der Compiler sich deinem inline widersetzt, dann weiß er schon, warum. Es ist sicher keine Alternative ein Makro zu nehmen.
-
Optimizer schrieb:
Wenn der Compiler sich deinem inline widersetzt, dann weiß er schon, warum.
das kann er ja schon ablehnen wenn die signatur bzw. parameterliste usw. ihm nicht passen, unabhängig vom 'body' der funktion. oder sehe ich das falsch?
-
Ich meine keine Compilerfehler, sondern, dass er eine Funktion nicht inlined, wovon du ja geredet hast.
-
In Effektiv C++ programmieren von Scott Meyers steht ein guter Text über inline und seine Gefahren (Richtlinie 33). Dort wird auch gesagt, dass alle Funktionen, die der Compiler als nicht inline akzeptiert, automatisch static werden. (Sie sind nur in der einen ÜE verfügbar). Das ist auch der Grund, warum man Templatemethoden in der Header als inline definiert, so dass es keine doppelte Definitionen der Methoden gibt. (Schlussendlich ein Linker-Fehler) Dass die Methoden als static deklariert wurden, hat natürlich auch seine Nachteile. Das liest man aber am besten bei Interesse im Buch selber nach.
-
ChrissiB schrieb:
In Effektiv C++ programmieren von Scott Meyers steht ein guter Text über inline und seine Gefahren (Richtlinie 33). Dort wird auch gesagt, dass alle Funktionen, die der Compiler als nicht inline akzeptiert, automatisch static werden.
Das ist käse. inline-Funktionen sind, sofern nicht anders deklariert, extern, haben also external-linkage. Es ist Aufgabe des Compilers dafür zu sorgen, dass es nur genau eine Instanz der Funktion gibt, falls die inline-Funktion nicht inline generiert wird oder deren Adresse gebildet wird.
Wenn Meyers das dort wirklich so schreibt, dann gilt das nur für Prä-Standard-C++ nicht aber für das C++ was wir kennen.
-
Update: Ich habe gerade in mein "Effective C++ - Second Edition 11th Printing" reingeschaut und da weißt Meyers korrekterweise darauf hin, dass das was du da oben schreibst nur für die "old outlined inline rules" gilt (sprich für ARM-C++).
Du solltest also mal über die Neuanschaffung einer neuen Version des Buches nachdenken. Aber warte noch ein bischen: Meyers schreibt gerade an einer dritten Ausgabe.
-
Hume, ich habe bisher auch nur einen Entwurf von vor 2 Tagen, und seitdem nicht viel dran gemacht. Der ist soweit noch nicht ganz korrekt (ich wußte nicht dass inline-Funktionene external Linkage haben -- heißt das nicht, ich kann generell jede Funktion inline deklarieren? Ich dachte immer das wär bei solchen in anderen ÜEs keine gute Idee) und didaktisch muss er auch nochmal überholt werden.
-
Bashar schrieb:
(ich wußte nicht dass inline-Funktionene external Linkage haben -- heißt das nicht, ich kann generell jede Funktion inline deklarieren?
Klar. Aber vergiss nicht dass die Regel, dass die *Definition* einer inline-deklarierten Funktion am Aufrufpunkt sichtbar sein muss unabhängig von linkage gilt.
D.h. wenn du eine Funktion inline-deklarierst, die Definition aber in ÜE1 hast und du dann diese Funktion in ÜE2 aufrufst, dann hast du undefiniertes Verhalten.Das Wichtigste was sich durch die Umstellung auf external-linkage geändert hat, ist die Tatsache, dass Funkions-statische Objekte nur einmal pro Programm und nicht einmal pro ÜE existieren.
-
HumeSikkins schrieb:
Klar. Aber vergiss nicht dass die Regel, dass die *Definition* einer inline-deklarierten Funktion am Aufrufpunkt sichtbar sein muss unabhängig von linkage gilt.
Ah OK danke, Weltbild wieder gerade gerückt
-
@Bashar
Mein Problem bei dem Text ist, dass inline von verschiedenen Ebenen betrachtet werden kann/muss.
Du hast die logische Ebene wo man sich fragt, wann/warum verwendet man inline?
Was sind die Kosten (Code-Größe, Geschwindigkeit, hohe Kopplung)? Was bringt es (Code-Größe, Geschwindigkeit)?
Dann hast du die C++ Ebene, wo man die Bedeutung von inline aus Sicht von C++ abklappern muss (inline ist nur ein Hinweis, inline beeinflusst ODR, inline-Semantik im Vergleich zu ARM usw.)
Schließlich hast du die technische Ebene wo man sich anschauen könnte, wie inlining funktioniert (Vergleich: Call vs. inline) und zu welchen Zeitpunkten es geschehen kann.
-
warum alles auf einmal?
dann doch eben nur ein faq text "inline und die odr"
-
Ich behandele speziell die Bedeutung des Schlüsselworts inline, weil da IMO die meisten Unklarheiten liegen. Also hauptsächlich die "C++-Ebene", wobei man den Rest natürlich nicht völlig außer Acht lassen kann.
-
Worin hat man die Vorteile von der ARM-Variante gegenüber der jetztigen variante gesehen? Oder hat schlicht und einfach niemand dran gedacht?
-
Das Wichtigste was sich durch die Umstellung auf external-linkage geändert hat, ist die Tatsache, dass Funkions-statische Objekte nur einmal pro Programm und nicht einmal pro ÜE existieren.
Auf den Beitrag von Bashar bin ich gespannt.
HumeSikkins: Ich habe hier die 3. deutsche Auflage, es ist die 2. englische Ausgabe vom Buch. Dort steht es (noch) so, wie ich es oben geschrieben habe. Wann wird denn die 3. Auflage ungefähr herauskommen?
-
Wann wird denn die 3. Auflage ungefähr herauskommen
Laut Scott Meyers ist "late spring" angepeilt. Ich würde also mal auf Spätsommer tippen
