headerdateien nach konvention erstellen ist langsam?

achso.
deshalb habe ich auch keinen unterschied bei der rechengeschwindigkeit gemerkt, als ich die funktionen mal inline und mal nicht-inline definiert habe.

wie kann ich die funktionen inline definieren UND in die v3.cpp schreiben?

wenn ich einfach in v3.h und v3.cpp "inline" davorschreibe, gibt es die meldung:

"v3.h [Warning] inline function const GLdouble& v3::operator[](int) const' used but never defined" und "[Linker error] undefined reference tov3::operator[](int) const'"

Chewie83

hermesasl schrieb:

wie kann ich die funktionen inline definieren UND in die v3.cpp schreiben?

Meines Wissens gar nicht, zumindest nicht mit der gegenwärtigen Sprachversion und den Compilern.

also wäre eine schnelle und trotzdem konventionelle möglichkeit, alle inlinefunktionen in der headerdatei zu lassen und die anderen (konstruktoren etc.) in v3.cpp zu definieren?

Nexus

hermesasl schrieb:

ich benutze dev-c++ 4.9.9.2 (mit standardcompilereinstellungen)

Davon solltest du wegkommen. Dev-C++ ist veraltet und wird nicht mehr weiterentwickelt. Zu empfehlen sind die kostenlosen IDEs Microsoft Visual C++ 2008 Express und Code::Blocks.

inpimp schrieb:

weil methoden welche im header definiert worden sind vom compiler als inline kandidaten drankommen.

methoden welche in der cpp hingegen nicht.

Seit wann ist das so? Der Compiler kann doch auch Inline-Optimierungen bei Funktionen in Implementierungsdateien vornehmen. Auf Linker-Ebene spielt es ja keine so grosse Rolle, wo die Funktionen definiert wurden. Ansonsten wäre die ganze Inlining-Optimierung nicht wirklich sinnvoll...

hermesasl schrieb:

also wäre eine schnelle und trotzdem konventionelle möglichkeit, alle inlinefunktionen in der headerdatei zu lassen und die anderen (konstruktoren etc.) in v3.cpp zu definieren?

Ja, zum Beispiel. Du kannst aber auch einen anderen Header mit den Inline-Funktionen machen und diesen am Ende der Klassendefinition einfügen, damit du die Trennung zwischen Schnittstelle und Implementierung bewahren kannst. Wobei es meiner Ansicht nach wie gesagt möglich sein sollte, dass der Compiler Nicht-Inline-Funktionen optimiert. Probier einfach einen aktuellen Compiler aus.

danke für die empfehlung zu code::blocks ... das gefällt mir ganz gut.

leider compiliert es eine datei nicht und ich weiß nicht, was falsch ist.

template <class P>
inline P max(P a,P b) {
      return (a>b)?c:b;
}

fehlermeldung:

error: expected `)' before "a"

kann da schnell jemand was sagen?
sorry, wollte wegen der kurzen frage kein extra-topic öffnen

sollte heißen: return (a>b)?a:b;

das problem besteht weiterhin

Mizar

hermesasl schrieb:

sollte heißen: return (a>b)?a:b;

das problem besteht weiterhin

Hmmm.. ich bin mir nicht ganz sicher, aber hast du es schonmal so probiert:

return (a > b ? a : b);

Bashar

Nexus schrieb:

inpimp schrieb:

weil methoden welche im header definiert worden sind vom compiler als inline kandidaten drankommen.

methoden welche in der cpp hingegen nicht.

Seit wann ist das so?

Falsche Frage. Richtiger: "Seit wann ist das nicht mehr so?" Was du als selbstverständlich annimmst erfordert schon einigen Aufwand seitens des Compiler/Linker-Gespanns.

Nexus

Bei dir ist std::max nicht im globalen Namensraum bekannt? Sowieso würde ich das benutzen, und bei einem eigenen Funktionstemplate einen anderen Namen wählen...

okay, danke für den tipp. funktioniert jetzt

Nexus

Bashar schrieb:

Falsche Frage. Richtiger: "Seit wann ist das nicht mehr so?" Was du als selbstverständlich annimmst erfordert schon einigen Aufwand seitens des Compiler/Linker-Gespanns.

Dann hätte man womöglich meine Frage falsch verstanden.

Und ich schätze es sehr, dass mir der Compiler und der Linker einige Arbeit abnehmen. Tut mir leid, wenn ich den Compilerbauern zu wenig Respekt gezollt habe.

hustbaer

Seit wann ist das so? Der Compiler kann doch auch Inline-Optimierungen bei Funktionen in Implementierungsdateien vornehmen.

Gute Compiler tun das auch.

MSVC z.B. kann das seit Version 8 aka. 2005 (ab Version 7.1 theoretisch, praktisch aber nicht zu empfehlen da zu buggy).

GCC kann das mit den passenden Einstellungen vermutlich auch, hab das aber nicht überprüft.

dooooomi

hustbaer schrieb:

Seit wann ist das so? Der Compiler kann doch auch Inline-Optimierungen bei Funktionen in Implementierungsdateien vornehmen.

Gute Compiler tun das auch.

MSVC z.B. kann das seit Version 8 aka. 2005 (ab Version 7.1 theoretisch, praktisch aber nicht zu empfehlen da zu buggy).

GCC kann das mit den passenden Einstellungen vermutlich auch, hab das aber nicht überprüft.

Nur daß ich das richtig verstehe, die Rede ist doch von Inline-Funktionen, die in einer anderen Übersetzungseinheit definiert sind, richtig?

Kann man irgendwo nachlesen, wie das beim MSVC funktioniert?

LordJaxom

dooooomi schrieb:

Kann man irgendwo nachlesen, wie das beim MSVC funktioniert?

Stichwort "linktime code generation".

EDIT:
Zum Beispiel http://msdn.microsoft.com/en-us/magazine/cc301698.aspx

natürlich habt ihr recht mit LTCG.

aber der thread starter wird mit seinem devc++ mitgelieferten compiler diesbezüglich nicht weit kommen

LordJaxom

inpimp schrieb:

natürlich habt ihr recht mit LTCG.

aber der thread starter wird mit seinem devc++ mitgelieferten compiler diesbezüglich nicht weit kommen

Darüberhinaus ändert LTCG ja auch nichts an der One Definition Rule, für die das Keyword inline immernoch von essentieller Bedeutung ist

Man kann es aber trotzdem mal erwähnt haben, da es schnell heißt, dass Inlining über Codefilegrenzen hinweg nicht möglich sei.

Bashar

LordJaxom schrieb:

Man kann es aber trotzdem mal erwähnt haben, da es schnell heißt, dass Inlining über Codefilegrenzen hinweg nicht möglich sei.

Das hat dann aber mit dem inline-Schlüsselwort nichts mehr zu tun, sondern ist eine Optimierung, die vollständig hinter den (durch den C++-Standard gegebenen) Kulissen abläuft.

Nexus

inpimp schrieb:

aber der thread starter wird mit seinem devc++ mitgelieferten compiler diesbezüglich nicht weit kommen

War also doch nicht so schlecht, ihm davon abzuraten.

hustbaer

Es ging ursprünglich um "effektiv inline", nicht um "grammatikalisch inline".
Und "effektiv inline" können eben manche Compiler dank LTCG (oder wie auch immer ein bestimmter Compiler es gerade nennt) auch mit Funktionen die nicht überall inkludiert werden und grammatikalisch eben auch nicht inline sind.

Nexus schrieb:

inpimp schrieb:

aber der thread starter wird mit seinem devc++ mitgelieferten compiler diesbezüglich nicht weit kommen

War also doch nicht so schlecht, ihm davon abzuraten.

das stimmt, danke
hab dev-c++ eh nur aus gewohnheit genutzt, aber die nicht-weiterentwicklung hat mich auch schon gewurmt. war nur noch zu unmotiviert, nach alternativen zu suchen.
find code::blocks gut, mich wundert da nur eine sache:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1620824.html#1620824

vielleicht hat ja jemand "aus diesem bereich hier" eine antwort