static inline

phlox81

Gast123 schrieb:

@phlox81
und in wie fern beantwortet das meine frage(n)?

Denken musst du selber

Evtl. wollen sie dadurch erreichen, das falls der compiler es nicht
inlined, die Methode static ist. Oder sie sofort Static ist,
aber dafür nicht inline. Oder doch. Kommt wohl auf den Compiler an.

Ridley

eine nicht statiche Methode einer Klasse ist in JEDER Instanz einer Klasse vorhanden. sie hat den this-pointer auf diese instanz, man kann somit member ansprechen, etc. pp.

eine statische methode einer klasse gibt es nur einmal. man benoetigt keine Instanz dieser Klasse um sie aufzurufen:

Klasse::StatischeMethode()

statische methoden haben kein this ( wo von auch? ) und koennen logischerweise nicht auf member zugreifen ( auf welche auch, bzw. wem sollten die member gehoeren ohne this?? ).
ausnahmen sind andere statische member.

camper

static sollte man zugunsten von unbenannten namespaces aufgeben. und nein, das hat keinen sinn. static i.V.m. freistehenden funktionen bewirkt internal linkage, macht das betreffended object also für den linker unsichtbar, damit kann es beim linken nicht zu konflikten wegen mehrfachdefinition kommen. falls die funktion wirklich in verschiedenen ÜEs verwendet wird, wird für jede ÜE dann eine eigene kopie der funktion angelegt, obwohl diese alle identisch sind.

@phlox81: eine definition von funktionen in der klassendefinition bewirkt auch nur, dass diese mehrfach identisch definiert werden dürfen, so wie es der fall ist, wenn die methode ausserhalb der klassenfunktion mit inline definiert wird. keinesfalls zwingt es den compiler zu irgendetwas bei der codeerzeugung.

ness

Doch, das hat sinn (keine ahnung, obs ne gcc extension ist). Ich zitiere mal sinngemäß linus:
static inline bedeuted: mach die funktion inline, aber wenn das nicht geht (es wird ein pointer drauf verlangt, optimierungen sind nicht eingeschaltet, ...), mache die funktion static. extern inline bedeutet: mach die funktion inline, aber wenn das nicht geht (es wird ein pointer drauf verlangt, optimierungen sind nicht eingeschaltet, ...), habe ich eine weitere nicht-inline implementierung.

camper

ness schrieb:

Doch, das hat sinn (keine ahnung, obs ne gcc extension ist). Ich zitiere mal sinngemäß linus:
static inline bedeuted: mach die funktion inline, aber wenn das nicht geht (es wird ein pointer drauf verlangt, optimierungen sind nicht eingeschaltet, ...), mache die funktion static. extern inline bedeutet: mach die funktion inline, aber wenn das nicht geht (es wird ein pointer drauf verlangt, optimierungen sind nicht eingeschaltet, ...), habe ich eine weitere nicht-inline implementierung.

also, nochmal:

static inline: eine out-of-line kopie pro ÜE sobald irgendwo in der ÜE die adresse dieser funktion benötigt wird, oder inlining in dieser ÜE wenigstens einmal nicht möglich bzw. nicht sinnvoll ist
nur inline: eine einzige out-of-line kopie im gesamten projekt falls irgendwo die adresse benötigt wird oder inlining wenigstens einmal fehlschlägt

wo war jetzt nochmal der vorteil von static inline

otze

Bei Klassen kann man es erzwingen in dem man die Methoden im Header spezifiziert.

nein, kann man nicht. Die Compiler ist da ziemlich eigen ;). Vielleicht machen es einige bei niedrigen optimierungslvln, aber das glaube ich nicht.

eine nicht statiche Methode einer Klasse ist in JEDER Instanz einer Klasse vorhanden. sie hat den this-pointer auf diese instanz, man kann somit member ansprechen, etc. pp.

Nein. zumindest würd ich den Compiler, der so meinen kostbaren Speicher verschwendet in den müll werfen.Wozu brauch ich 50 mal fast dieselbe funktion, wenn sich nur die Basisaddressen der Objekte ändern? Es ist eher so, dass die funktion vom compiler den this pointer als zusätzliches Argument übergeben bekommt.

Hier ein Beispiel wie ein Compiler das machen könnte(denn alle compiler sind verschieden):

//erstmal so wie man es schreibt
class Foo{
    private:
        int i;
        short j;
    public:
        void doSth(){
            i=5;
            j=3;
        }
}

Foo foo;
foo.do_sth();
//und sowas kann der Compiler draus machen(Pseudocode):
struct Foo{
    int i;
    short j;
};
void doSth(void* pos){
    //da wir einen POD typ haben, liegt am basisofset direkt der integer wert, und 4 bytes weiter der short wert. 
    //Kommt vererbung ins spiel wird das ganze sofort viel komplexer...
    (*(int*)pos)=5;
    (*(short*)pos+4)=3;
}

Foo foo;
doSth((void*)&foo);

den Compiler intressiert es also garnicht, wo die einzelnen Objekte liegen, da er nur mit offsets arbeitet.

ich weiss nicht was ihr mit klassen am hut habt. mir gehts nur um einzelne funktionen, ich bau mir doch keine klasse math um dort dann so zeugs wie LogN und co. unterzubringen, faende ich jetzt viel zu umstaendlich, zumal es auch spezialisierte versionen geben kann fuer komplexe zahlen zum beispiel.

also wenn ich das von ness richtig interpretiere, ist es auf keinen fall ein fehler ein static vor allen inline-funktionen zu haben die nicht innerhalb einer klasse liegen?

nachdem ich nun einige funktionen in meinem aktuellen projekt mit static inline (die vorher nur inline waren) versehen habe, ist die ausführbare exe um einiges grösser geworden.

camper

Gast123 schrieb:

nachdem ich nun einige funktionen in meinem aktuellen projekt mit static inline (die vorher nur inline waren) versehen habe, ist die ausführbare exe um einiges grösser geworden.

ich habe das bereits zweimal erklärt...

ness

Natürlich ist es ein Fehler, _alle_ funktionen die inline sind zusätzlich static zu machen. Es ist genau so, wie camper erklärt hat. Bei größeren projekten mit internen headern und inline fuktionen kann static iline aber sinnvol sein, um kollisionen zu vermeiden/beheben.

camper

dafür gibts dann unbenannte namespaces

ness

Ja, aber nicht in C (OK, ist im c++ forum kein argument).