"use namespace" in header läst sich nicht vermeiden ?!, help!

[T0bi]

hi,
Ich habe mir eben ein neues Project angelegt und auch sofort ne neue klasse hinzugefügt. dann hab ich im header der stdafx.h alle nötigen header eingebunden. ich will in meiner neuen klasse nun aber strings benutzen und andere für den compiler da noch fremde typen, dann ist es doch da richtig die stdafx.h oder halt die benötigten header in den header file der klass einzubinden oder? beim string header ist das aber sone sache, weil ich auch wenn der header eingebunden ist, ich noch keine variablen des types string deklarieren kann, eil ich noch den namespace std brauche, nun hab ich aber gelsen das man using namespace nur in .cpp datein benutzen soll.

Was soll ich jetzt tun?

Gruß Tobi.

[CStoll]

Anstatt das using zu verwenden, kannst du auch explizit auf den Namensraum zugreifen, indem du ein "std::" vor den Bezeichner setzt.

[T0bi]

ok, aber es ist trotzdem ok wenn ich dann die stdafx.h in meinen klassen header includiere oder?

[CStoll]

technisch ja, praktisch ist es besser, überall nur die tatsächlich benötigten Header einzubinden (sprich: Wer mit std::string arbeitet, includet die <string> etc). Die präcompilierten Header sind eher zum Sammeln der WinAPI-Deklarationen nützlich.

[T0bi]

ok also in den klassen header komm nur header rein die ich tatsächlich brauch an sonsten kommt alles in die stdafx, gut danke

[hustbaer]

MSVC hat einen bösen Bug was precompiled headers angeht.
Wenn man Dateien in unterschiedlichen Verzeichnissen liegen hat:

/foo
/foo/stdafx.h
/foo/foo.h
/foo/main.cpp
/bar
/bar/stdafx.h
/bar/bar.h

Wenn nun in foo.h und bar.h jeweils einfach ein

#include "stdafx.h"

steht... dann sollte man ja annehmen dass foo.h auch /foo/stdafx.h inkludiert und bar.h eben /bar/stdafx.h.
Nun angenommen main.cpp enthält

#include "stdafx.h"
#include "foo.h"
#include <bar/bar.h> // include pfad muss entsprechend gesetzt sein damit bar.h gefunden wird

Wenn man aber MSVC verwendet, und das Projekt so einstellt dass MSVC "stdafx.h" als Precompiled Header verwenden, dann ... passiert nicht was passieren sollte.
Was passieren sollte:

#include "stdafx.h"
  --> /foo/stdafx.h wird inkludiert
#include "foo.h"
  --> /foo/foo.h wird inkludiert
  #include "stdafx.h"
    --> /foo/stdafx.h wird inkludiert
#include <bar/bar.h>
  --> /bar/bar.h wird inkludiert
  #include "stdafx.h"
    --> /bar/stdafx.h wird inkludiert
...

Was wirklich passiert:

#include "stdafx.h"
  --> MSVC sieht "stdafx.h", denkt sich "uh, yummy, stdafx.h ist die header vom PCH" -> PCH file laden
#include "foo.h"
  --> /foo/foo.h wird inkludiert
  #include "stdafx.h"
    --> MSVC sieht "stdafx.h", denkt sich "uh, yummy, stdafx.h ist die header vom PCH" -- PCH file ist aber schon geladen -> MSVC macht einfach nix
#include <bar/bar.h>
  --> /bar/bar.h wird inkludiert
  #include "stdafx.h"
    --> MSVC sieht "stdafx.h", denkt sich "uh, yummy, stdafx.h ist die header vom PCH" -- PCH file ist aber schon geladen -> MSVC macht einfach nix
...

Anders gesagt: MSVC ignoriert bei der Entscheidung ob es sich bei einer include Zeile um das "passende include" zum PCH handelt vollkommen den aktuellen include Suchpfad. Egal in welchem File include "stdafx.h" steht, es wird immer das PCH file geladen und NICHT das File welches ohne die Verwendung von PCH geladen würde.

Und das ist einer der Gründe warum man NIEMALS die Header die für's PCH verwendet wird in einer anderen (öffentlichen) Header inkludieren sollte.

Ein anderer guter Grund: die Header für's PCH ist normalerweise "privat", d.h. die "darf" man garnicht aus "öffentlichen" Headers inkludieren.

p.S.: "stdafx.h" ist natürlich nur ein Platzhalter der für den Namen der "PCH Header" steht.

[Martin Richter]

Hast Du das in VS2005 verifiziert und einen Bugreport geschrieben?

[hustbaer]

Mit MSVC 2005 noch nicht gecheckt, nö.
Werd ich mal machen.
Und... hast du mal nen Link wo ich Bug Reports schreiben kann?

[Martin Richter]

Der sicherste Weg ist es den Microsoft Support direkt zu kontaktieren.
Wenn Du ein MSDN Abo hast, dann dessen Nutzung der aller einfachste Weg.
Allerdings muss man aktuell in fast allen Fällen erstmal anrufen. Dann wirst Du zurück kontaktiert.
Direkte Links wüsste ich nicht mehr.

Connect dient nur noch VS2008... Bugs zu VS2005 werden dort meistens sofort abgewiesenn.