Methoden die der Comiler eh inlined: inline angeben?

Lars

Also es geht um kleine Methoden die vom Compiler (wahrscheinlich) eh geinlined würden: Sollte man trotzdem 'zusätzlich' inline angeben oder nicht?

Ich bin der Meinung, dass man es angeben sollte, da man sich nicht unbedingt auf die Taten des Compilers verlassen sollte. Und schließlich schadet es ja auch nicht.

Dimah war dagegen:

Dimah: ja klar
Lars: das sind nähmlich nur ein-zwei Zeiler bei mir
Lars: ok
Lars: dnake
Dimah: wenn sie zwei zeiler sind wird sie der compiler so oder so inlinen
Lars: ich weiss
Lars: aber man sollte es doch trotzdem
Lars: machen
Dimah: ne
Lars: da gabs mal ne Diskussion in nem Thread von mir
Lars: und am Ende hiess es: inlinen
Dimah: ne
Dimah: es hies inline ist gut
Dimah: das es in c++ standard drin ist als keyword
Dimah: aber es hies nicht inlinen
Dimah: es gibt fälle wo der user den compiler nachhelfen muss
Dimah: aber gänerel macht es der compiler besser
Lars: aber ob ich es angebe oder nicht ist doch egal also kann ich angeben
Dimah: jaein
Dimah: egal
Lars: Ich frag mal im Forum die Profis

So jetzt will ich eure Meinung hören

Shade Of Mine

inline ist eine Empfehlung an den Compiler.

dh, im Grunde macht ers eh so wie ers will.
ich habe inline noch nie verwendet...

Lars

1 dagegen
PS: ich weiss auch das es eine Empfehlung ist aber trotzdem...

Gerard

wieso ich gegen bin, wenn du einmal irgen wo inline schreibst finde ich dan solltes du bei jeder funkion überlegen ob du auch bei ihr inline schreiben solltest, kommt jetz eine funkion wo du dir aber nicht sicher bist was besser ist läst du dan das inline weg?
somit hast du 3 verscheidene zustände, einmal wo du weisst inline, einmal wo du nicht weist "nicht inline" und einmal wo du ka ahnung hast, solange es den keine ahnung fall bei dir gibt würde ich komplet auf das inline keywort verzichten

e: so was nene ich inkonsistenz

[ Dieser Beitrag wurde am 27.06.2002 um 15:23 Uhr von Dimah editiert. ]

HumeSikkins

Hallo,
wenn du die Methoden inline haben willst, schreib inline davor bzw. definiere sie innerhalb der Klassendefinition.

Ansonsten kein inline und Methodendefinition außerhalb der Klassendefinition am Besten in eine cpp-Datei.

Achja, und standardmäßig sollten alle deine Methoden nicht inline sein. Erst wenn du durch inlining messbare Vorteile hast, würde ich den Nachteil der höheren Kopplung den inline-Methoden haben in Kauf nehmen.

Lars

jo klar wenn ich mir nicht sicher bin, lass ich auch inline weg, aber wenn ich mir sicher bin, das es nützt, dann setzte ich es.
Und meistens hat man in einer Klasse eh so unmengen Ein bis Dreizeiler die man eigentlich immer inlinen kann:

class String
{
  private:
    TCHAR *string;
    unsigned long size;
    unsigned long len;

  public:
    inline String(void);
    inline String(unsigned long);
    inline String(const TCHAR);
    inline String(const TCHAR *);
    inline String(const String &);
    inline ~String();

    inline unsigned long length(void);
    inline void replace(const TCHAR);
    void replace(const TCHAR *);
    inline void replace(const String &);
    inline void append(const TCHAR);
    void append(const TCHAR *);
    inline void append(const String &);

    inline TCHAR getCharAt(unsigned long);
    inline void setCharAt(TCHAR, unsigned long);
    unsigned long indexOf(TCHAR *, unsigned long);

    inline int compareTo(TCHAR);
    inline int compareTo(TCHAR *);
    inline int compareTo(String);

    inline String &operator=(const TCHAR);
    inline String &operator=(const TCHAR *);
    inline String &operator=(const String &);
    inline String &operator+=(const TCHAR);
    inline String &operator+=(const TCHAR *);
    inline String &operator+=(const String &);

    inline TCHAR &operator[](unsigned long);
    const String operator()(unsigned long, unsigned long);

    inline String operator+(const TCHAR);
    inline String operator+(const TCHAR *);

    inline bool operator<(const TCHAR);
    inline bool operator<(const TCHAR *);
    inline bool operator<(const String &);
    inline bool operator<=(const TCHAR);
    inline bool operator<=(const TCHAR *);
    inline bool operator<=(const String &);
    inline bool operator==(const TCHAR);
    inline bool operator==(const TCHAR *);
    inline bool operator==(const String &);
    inline bool operator!=(const TCHAR);
    inline bool operator!=(const TCHAR *);
    inline bool operator!=(const String &);
    inline bool operator>=(const TCHAR);
    inline bool operator>=(const TCHAR *);
    inline bool operator>=(const String &);
    inline bool operator>(const TCHAR);
    inline bool operator>(const TCHAR *);
    inline bool operator>(const String &);

    friend const String operator+(const TCHAR, const String &); //Alle 3 sind inline
    friend const String operator+(const TCHAR *, const String &);
    friend const String operator+(const String &, const String &);
};

27 inline 3 nicht
es kommen noch ca. 5 nicht inline und 15 inline funktionen hinzu.
Also bei mir überwiegen die inline's egal wo grundsätzlich...

HumeSikkins

Hallo,
dir ist aber klar, dass du inline-Methoden nicht in seperaten cpp-Dateien definieren kannst, oder? (ich gehe mal davon aus, dass niemand auf dieser Welt #include <datei.cpp> schreibt)

SideWinder

Niemals nie Konstruktoren inlinen ... die sehen nur so kurz aus ;).

Methoden wie append() und replace() zu inlinen finde ich ebenfalls weniger gut.

Ich sehe bei dir nur wenige Möglichkeiten Inlining herzunehmen - eine sichere wäre die Methode length().

MfG SideWinder

Lars

Original erstellt von SideWinder:
**Niemals nie Konstruktoren inlinen ... die sehen nur so kurz aus ;).
**

Ok danke

**
Methoden wie append() und replace() zu inlinen finde ich ebenfalls weniger gut.
**

Das sind jeweil 3 überladene wobei die mit "TCHAR" und "String &" als Parameter nur die mit "TCHAR *" aufrufen und nur kurze Umwandelungen machen...

**
Ich sehe bei dir nur wenige Möglichkeiten Inlining herzunehmen - eine sichere wäre die Methode length().

MfG SideWinder**

Warum dass denn
length ist doch nur ein return

Lars

Original erstellt von HumeSikkins:
Hallo,
dir ist aber klar, dass du inline-Methoden nicht in seperaten cpp-Dateien definieren kannst, oder? (ich gehe mal davon aus, dass niemand auf dieser Welt #include <datei.cpp> schreibt)

Darf ich nicht die Deklaration

inline unsigned long length(void);

in die string.h und die deklaration in die .cpp tun:

unsigned long String::length(void)
{
    return(len);
}

Nicht wirklich oder :o Das wäre doch total unübersichtlich

HumeSikkins

Niemals nie Konstruktoren inlinen ... die sehen nur so kurz aus

Was läßt dich zu dieser Regel kommen bzw. was spricht gegen inline Konstruktoren?

Und warum sollten Konstruktoren in diesem Fall kürzer aussehen, als sie sind? Hier ist ja weder Vererbung im Spiel noch müssen irgendwelche Ctors irgendwelcher Memberobjekte aufgerufen werden.

Shade Of Mine

fuer meinen Geschmack viel zu viel schreibarbeit... und verdammt hohe abhaengigkeit, quasi die ganze klasse ist inline... also mir gefaellt das garnicht (von dem total unleserlich mal abgesehen)

HumeSikkins

Darf ich nicht die Deklaration

inline unsigned long length(void);

in die string.h und die deklaration in die .cpp tun:

unsigned long String::length(void)
{
return(len);
}

Nope. Das geht nicht. Eine inline-Methode/Funktion muss in jeder Übersetzungseinheit definiert sein.

Es gibt drei mir bekannte Wege für die Benutzung von inline-Methoden:
1. Methodendefinition innerhalb der Klassendefinition:

class Foo
{  
    public:
        // Func ist automatisch inline. Ein explizites inline ist überflüssig
        void Func()
        {
            // ...
        }
};

2. Methodendefinition außerhalb der Klassendefinition, aber im Header:

class Foo
{
    public:
        // das inline kann entweder bei Deklaration, bei der Definition
        // oder bei beiden stehen. 
        inline void Func();
};

inline void Foo::Func()
{
//...
}

3. Die Definitionen der Inline-Methoden kommen alle in eine extra .inl-Datei. Diese wird als letztes im Header inkludiert.

// Foo.h
class Foo
{
    public:
        inline void Func();
        inline void Func2();

};
#include "Foo.inl"

// Foo.inl
inline void Foo::Func()
{
//...
}
inline void Foo::Func2()
{
//...
}

Christoph

@Lars Skiba:
Nein das darfst du nicht, die Implementierung muss bei inline im Header stehen.

Es gibt auch noch ein paar Ausnahmen:
Aus MSDN (Auszug):

You cannot inline a function if:

The function and the caller use different types of exception handling (C++ exception handling in one, structured exception handling in the other).

The function has a variable argument list.

The function uses inline assembly and is not compiled with /Og, /Ox, /O1, or /O2).

Function returns an unwindable object by value and is not compiled with /GX, /EHs, or /EHa).

The function receives a copy-constructed object passed by value, when compiled with /GX, /EHs,, or /EHa.

The function is recursive.

The function is virtual.

The program takes the address of the function.

Lars

Mir gefällt der 3. Weg am besten, den nehm ich

SideWinder

Das sind jeweil 3 überladene wobei die mit "TCHAR" und "String &" als Parameter nur die mit "TCHAR *" aufrufen und nur kurze Umwandelungen machen...

Hab ich vergessen - dann eignen sie sich natürlich für Inline.

Warum dass denn
length ist doch nur ein return

Eben darum ist sie ja eine von den wenigen die ich Inline machen würde.

Was läßt dich zu dieser Regel kommen bzw. was spricht gegen inline Konstruktoren?

Hab ich einmal den Meyers gelesen und hab ihn erst nicht verstanden...

Also dort steht (Effective C++, Scott Meyers):

In der Tat sind Konstruktoren und Destruktoren meist schlechte Kandidaten für inline-Funktionen, als eine oberflächliche Betrachtung vermuten lassen würde.

Danach steht was über die von dir angesprochene Vererbung (welche wir tatsächlich hier nicht haben). Aber es steht noch mehr in diesem Buch. Und zwar müssen die Compiler im Konstruktor noch nachträglich Code einfügen, welcher zwar nicht Standard-C++ ist allerdings für das Erstellen der Objekte wichtig ist. Dieser Code würde dann natürlich ebenfalls inline werden.

MfG SideWinder

HumeSikkins

Jo. Ich kenne das Buch.

Ich finde da halt nur nichts das in die Richtung "nie nie nie" geht.
Besonders da automatisch generierte Ctor und Dtors normalerweise immer inline generiert werden.

Kurz: Ich kenne keine Rechtfertigung für deine Regel. Deshalb habe ich ja nachgefragt

Real_PsychoDAD

Hi,

also ich will hier mal eine Erfahrung, die ich mit inline machte, posten.
Gegeben ist folgende Klasse :

class MScoreCounter
{
public:

    // Singleton
    static MScoreCounter& GetInstance() 
    {       
        static MScoreCounter Instance;
        return Instance;
    }

    void  IncScore(const MEnemy* p)
    {
        m_LastScore = p->GetPoints();
        m_Score += m_LastScore;    
    }

    int   GetScore() const 
    {
        return m_Score;
    }

    int   GetLastScore() const
    {
        return m_LastScore;
    }

private:

    int   m_Score;

    int   m_LastScore;    // Die Höhe der zuletzt addierten Punkte

private:
    MScoreCounter() : m_Score(0),m_LastScore(0) {}
    MScoreCounter(const MScoreCounter&);

    MScoreCounter& operator=(const MScoreCounter&);
};

sieht doch alles korrekt aus.
Es lief auch alles prima, solange ich im Debug Modus ( MSVC6 ) compilierte. Und am Ende meines Projektes compilierte ich alles nochmal im Release, spielte eine Probepartie und erlebte eine Überraschung. In der Klasse Game konnte ich die Punkte immernoch perfekt auslesen, aber als ich diese Klasse dann zerstörte und meine HighScrore Klasse aufrief, welche über GetPoints die Punkte ausliess, bekamm ich nur noch Müll. Abhilfe schaffte es alles in eine cpp Datei zu packen, also auf inline zu verzichten.
Ich weiss nicht genau woran es lag, aber ich denke das statische Variablen und inline sich beissen.
Nun verwende ich kaum noch inline und was ich damit sagen will weiss ich auch nicht, aber ich musste es einfach mal posten
Aber vielleicht bin ich auch nur der einzige Trottel mit solch einem Fehler, mein Visual scheint sowieso kaputt zu sein

volkard

Original erstellt von Real_PsychoDAD:
**Hi,
Ich weiss nicht genau woran es lag, aber ich denke das statische Variablen und inline sich beissen.
**

So isses. Abgesehen davon ist inline aber nicht böse.

volkard

Original erstellt von Lars Skiba:
Mir gefällt der 3. Weg am besten, den nehm ich

Hmm. Für die Übersichtlichkeit bringt er nix.
Aber, mal sehen, man könnte sowas versuchen, daß nicht die *.h die *.inl inkludiert, sondern Umgekehrt!
Und wer nur den Typ ohne Größe braucht, macht ne Forward-Deklaration, wer den Typ mit Größe braucht, macht #include "bla.h" und wer nen voll funktionierenden Typ braucht, macht #include "bla.inl".
Hat sowas schonmal jemand versucht? Wir ging es aus?
edit: statt .h lieber _fwd.h und statt .inl lieber .h, ist aber erstmal egal, mir gehts mal nur um die Senkung der Abhängigkeiten.

[ Dieser Beitrag wurde am 27.06.2002 um 19:42 Uhr von volkard editiert. ]