Forward-Deklarationen auf STL Klassen

7H3 N4C3R

Hi,

ich habe mal eine Frage bezüglich STL Klassen (hier z.B. String:) und Forward-Deklarationen

Beispiel.h:

class Test
{
public:
  Test( const std::string& name);
}

Da Name nur eine Referenz auf einen std::string ist, ist es ja nicht nötig, dass die Klassendeklaration schon im Header bekannt ist. Allerdings - wie mache ich eine Forward-Deklaration auf std::string (was ja nur ein typedef auf basic_string<char, ...> ist)? Das Problem ist ja, dass jede STL-Implementation nach den im Standard vorgeschriebenen Template-Parametern auch noch eigene definieren darf, was es erstmal unmöglich macht, eine portable Forward-Deklaration aufzuschreiben.

Bei den stream-Klassen wurde das ganze durch den <iosfwd> Header gelöst. Gibt es etwas analoges für die restliches STL-Klassen, wie string, vector, etc?

Gruß

HumeSikkins

Gibt es etwas analoges für die restliches STL-Klassen, wie string, vector, etc?

Nope. Gibt es nicht. Und wie du schon richtig erkannt hast, ist das portabel auch nicht so ohne weiteres zu machen. Wenn es auf Portabilität (bezüglich der Standardlib) nicht ankommt, kannst du dir für deine STL-Implementation natürlich passende Header bauen.
Alternativ bleibt dir nur, Wrapper-Klassen für die STL-Container zu schreiben. Dafür kannst du dann ohne Probleme Vorwärtsdeklarationen bauen. Bevor du damit anfängst, solltest du aber erstmal ausmessen, ob dir das wirklich etwas bringt.
Da man STL-Container meist als Member "by-value" verwendet, musst du in den meisten Fällen sowieso die vollständige Definition einbinden. Die Fälle wo man solche Container indirekt verwendet (Pointer, PIMPL usw) dürften in der Regel so selten sein, dass das Includieren der Definition keine nennenswerten Verzögerungen mit sich bringt. Und Angst vor Änderungen in den STL-Headern (und damit verbundenen Neukompilierungen) musst du ja auch nicht haben.

7H3 N4C3R

Hmm... das ist das, was ich vermutet habe.

In meinem Fall hätte ich nur einen Konstruktor-Parameter, aber kein Member dazu in der Klasse. Um Header-Änderungen geht es mir auch nicht, aber man könnte sich z.B. ein dickes #include <vector> sparen. Naja und da das ganze auf mindestens 3 verschiedenen STL-Implementierungen verwendet wird, bleibt mir wohl nix anderes übrig als das include. Trotzdem danke für die Antwort.