Wo header inkludieren?

[DEvent]

rüdiger schrieb:

Ne, er muss ja zumindest die Größe eines std::string-Objektes kennen.

Ja stimmt, das habe ich vergessen.

rüdiger schrieb:

Und wenn es gar nicht erst inline ist, kann er die nur schwer inlinen. Außerdem ist es wichtig, um das Linkage für die Methode/Funktion richtig hinzubekommen. Ob der Compiler es nun für sinnvoll hält die Methode zu inlinen oder nicht, ist ne andere Sache.

Das verstehe ich nicht ganz. Der Compiler entscheidet, ob die Methode inline wird oder nicht. Also wozu dann das inline Schluesselwort?

Aus http://www.parashift.com/c++-faq-lite/inline-functions.html:

There are several ways to designate that a function is inline, some of which involve the inline keyword, others do not. No matter how you designate a function as inline, it is a request that the compiler is allowed to ignore: it might inline-expand some, all, or none of the calls to an inline function.

[9.3] Do inline functions improve performance?
Yes and no. Sometimes. Maybe.

There are no simple answers. inline functions might make the code faster, they might make it slower. They might make the executable larger, they might make it smaller. They might cause thrashing, they might prevent thrashing. And they might be, and often are, totally irrelevant to speed.

Das sind mir irgendwie zu viele "vielleicht", "vielleicht nicht". Ist es da nicht das beste das inline Keyword ueberhaupt nicht zu benuzten und dem Compiler somit freie Hand lassen?

[Xin]

rüdiger schrieb:

Xin schrieb:

rüdiger schrieb:

1. ist es absolut verboten für den User was in den std-Namespace zu packen

Ich packe nichts rein. Ich behaupte nur, dass es std::string gibt.

Und das darfst du nicht, selbst wenn es std::string in der Form gäbe.

Wer sagt das?

Entweder stimmt die Deklaration, dann spare ich Zeit beim kompilieren.
Oder es stimmt nicht, dann kann ich nicht kompilieren.

rüdiger schrieb:

Xin schrieb:

rüdiger schrieb:

2. std::string ist ein typedef auf std::basic_string<char>!

Das wiederum ist ein Argument.
Das war auch auf eigene Klassen gemünzt. Statt das angefragte Beispiel weiterzunutzen, hätte ich hier besser eine irgendeine Beispiel-Klasse genommen.

Wohl war, aber das Modell ist eben nicht auf die Standard-Lib oder andere Libraries 3. übertragbar!

Ich kann mich nicht erinnern, irgendwas im Bereich std deklariert zu haben, aber ich sehe da jetzt keinen Grund für, es nicht zu tun und Du lieferst mir keinen, außer "Du darfst das nicht".

Gesetze ohne Begründung interessieren mich nur, wenn bei Zuwiderhandlung nennenswerte Strafen stehen. Andernfalls interessiert mich die Lösung des Problems mehr.

DEvent schrieb:

rüdiger schrieb:

Und wenn es gar nicht erst inline ist, kann er die nur schwer inlinen. Außerdem ist es wichtig, um das Linkage für die Methode/Funktion richtig hinzubekommen. Ob der Compiler es nun für sinnvoll hält die Methode zu inlinen oder nicht, ist ne andere Sache.

Das verstehe ich nicht ganz. Der Compiler entscheidet, ob die Methode inline wird oder nicht. Also wozu dann das inline Schluesselwort?

Inline heißt, dass Du eine Funktion im Header verfügbar machen musst (und darfst) und dass der Compiler den Ratschlag erhält, die Funktion nicht zu rufen, sondern an den Aufrufen einzukompilieren.

DEvent schrieb:

Das sind mir irgendwie zu viele "vielleicht", "vielleicht nicht". Ist es da nicht das beste das inline Keyword ueberhaupt nicht zu benuzten und dem Compiler somit freie Hand lassen?

Benutze inline dann, wenn Du sicher bist, dass die Funktion nicht zu einer Library gehört und sich ändern könnte. Alte Programme würden dann nicht die Funktion rufen, sondern die veraltete Version einkompiliert haben.
Komplexe und aufwendige Funktionen sind mit großer Wahrscheinlichkeit nicht für inline gedacht. Hier kann der Compiler sich auch gegen den Ratschlag wenden und die Inline-Funktion als normale Funktion umsetzen.

Für einfache Getter und Setter hilft inline, die Aufrufe (dadurch, dass sie nicht stattfinden) zu beschleunigen.

[rüdiger]

DEvent schrieb:

rüdiger schrieb:

Ne, er muss ja zumindest die Größe eines std::string-Objektes kennen.

Ja stimmt, das habe ich vergessen.

rüdiger schrieb:

Und wenn es gar nicht erst inline ist, kann er die nur schwer inlinen. Außerdem ist es wichtig, um das Linkage für die Methode/Funktion richtig hinzubekommen. Ob der Compiler es nun für sinnvoll hält die Methode zu inlinen oder nicht, ist ne andere Sache.

Das verstehe ich nicht ganz. Der Compiler entscheidet, ob die Methode inline wird oder nicht. Also wozu dann das inline Schluesselwort?

Das inline Schlüsselwort dient vor allem dem Linker

// foo.h
void dosth() { /* ... */ }

// foo.cpp
#include "foo.h"

// main.cpp
#include "foo.h"

int main() { }

wird sonst ein Linkerfehler schmeißen, da dosth in zwei Übersetzungseinheiten vorhanden ist. Mit inline legt der Linker in jedem Objekt eine Kopie an oder ist zumindest in der Lage den Konflikt aufzulösen.

Ist es da nicht das beste das inline Keyword ueberhaupt nicht zu benuzten und dem Compiler somit freie Hand lassen?

Wenn der Compiler die Implementierung der Methode nicht sieht, wird er sie auch nicht inlinen können. Mittlerweile sind die Linker zwar schon etwas intelligenter geworden. Aber darauf kann man sich nicht verlassen.

Xin schrieb:

rüdiger schrieb:

Xin schrieb:

rüdiger schrieb:

1. ist es absolut verboten für den User was in den std-Namespace zu packen

Ich packe nichts rein. Ich behaupte nur, dass es std::string gibt.

Und das darfst du nicht, selbst wenn es std::string in der Form gäbe.

Wer sagt das?

Der C++ Standard...

Xin schrieb:

rüdiger schrieb:

Xin schrieb:

rüdiger schrieb:

2. std::string ist ein typedef auf std::basic_string<char>!

Das wiederum ist ein Argument.
Das war auch auf eigene Klassen gemünzt. Statt das angefragte Beispiel weiterzunutzen, hätte ich hier besser eine irgendeine Beispiel-Klasse genommen.

Wohl war, aber das Modell ist eben nicht auf die Standard-Lib oder andere Libraries 3. übertragbar!

Ich kann mich nicht erinnern, irgendwas im Bereich std deklariert zu haben, aber ich sehe da jetzt keinen Grund für, es nicht zu tun und Du lieferst mir keinen, außer "Du darfst das nicht".

Gesetze ohne Begründung interessieren mich nur, wenn bei Zuwiderhandlung nennenswerte Strafen stehen. Andernfalls interessiert mich die Lösung des Problems mehr.

Schau halt in den Standard Wie gesagt, es gibt STL-Implementierungen, die zB mehr Template-Parameter haben (Dinkumware macht das AFAIK). Was absolut konform ist! Also wirst du dich bei so etwas aus Ärger einstellen müssen.

Und precompiled Header und "intelligentere" Precompiler haben das Problem ja ohnehin reduziert.

[DEvent]

rüdiger schrieb:

Das inline Schlüsselwort dient vor allem dem Linker

Tolle Sprache, die dem Linker dient. Die Sprache soll mir dienen. Ich hoffe sowas wird im C++0x ausgebessert.

[Xin]

rüdiger schrieb:

Xin schrieb:

rüdiger schrieb:

Xin schrieb:

Ich packe nichts rein. Ich behaupte nur, dass es std::string gibt.

Und das darfst du nicht, selbst wenn es std::string in der Form gäbe.

Wer sagt das?

Der C++ Standard...

Du hast nicht zufällig die Stelle parat, wo steht, dass ich eine Deklaration nicht von Hand benutzen darf? Schließlich definiere ich nichts Neues in std nicht, oder definiere vorhandenes um, sondern behaupte nur, dass es etwas gibt.

Ist dem nicht so, oder ist meine Behauptung falsch, werde ich darauf hingewiesen.

[camper]

Xin schrieb:

Du hast nicht zufällig die Stelle parat, wo steht, dass ich eine Deklaration nicht von Hand benutzen darf? Schließlich definiere ich nichts Neues in std nicht, oder definiere vorhandenes um, sondern behaupte nur, dass es etwas gibt.

Es geht nicht um Definitionen sondern um Deklarationen. Und da ist im Namensraum std für den Nutzer alles bis auf eine kleine Ausnahme verboten. Die kleine Ausnahme betrifft Spezialisierungen (partiell oder explizit) von Templates für Parametertypen, die der Nutzer selbst definiert hat (durch letzteres verhindern wir, dass man die partielle Ordnung für andere Typen durcheinanderbringen kann - mithin ist die Semantik für andere Typen nicht veränderbar). Zu finden in 17.4.2.1 [lib.using.headers]/3 (verbietet effektiv jede Form von Vorwärtsdeklaration - selbst wenn die exakte Signatur bekannt ist) und 17.4.3.1 [lib.reserved.names]/1 des Standards.

Ein Problem besteht sowieso nicht. Der weit überwiegende Teil der Definitionen in der Standardbibliothek betrifft Templates und die brauchen wir sowieso, wenn wir das entsprechende Template benutzen wollen. Eine reine Vorwärtsdeklaration ist wird nur in wenigen Fällen in der gesamten ÜE ausreichen.

[Xin]

camper schrieb:

Zu finden in 17.4.2.1 [lib.using.headers]/3 (verbietet effektiv jede Form von Vorwärtsdeklaration - selbst wenn die exakte Signatur bekannt ist) und 17.4.3.1 [lib.reserved.names]/1 des Standards.

Akzeptiert.

So einfach kann es sein, mich zu überzeugen, obwohl ich ja laut diversen hier alle Argumente ignoriere. ;->

camper schrieb:

Ein Problem besteht sowieso nicht. Der weit überwiegende Teil der Definitionen in der Standardbibliothek betrifft Templates und die brauchen wir sowieso, wenn wir das entsprechende Template benutzen wollen. Eine reine Vorwärtsdeklaration ist wird nur in wenigen Fällen in der gesamten ÜE ausreichen.

Wie gesagt, das ging vorrangig in die Richtung Verwendung eigener Klassen.
Wenn man sich die halbe Standard-Lib reinzieht, hört auch irgendwann der Spaß auf. Ob die Header nun abschreibt oder inkludiert... dann lieber einbinden...

Für eine einzelne Klasse sehe ich das aber durchaus als sehr sinnvoll an (bei eigenen Klassen).

[rüdiger]

DEvent schrieb:

rüdiger schrieb:

Das inline Schlüsselwort dient vor allem dem Linker

Tolle Sprache, die dem Linker dient. Die Sprache soll mir dienen. Ich hoffe sowas wird im C++0x ausgebessert.

hä?