<iostream.h> wird in VisualStudio 2008 nicht erkannt

[moehrle]

Hallo, habe folgendes Problem. In einer Win32-Konsolenanwendung mit Funktionen wie cin und cout wird einfach die eingebundene Header-Datei <iostream.h>, <string.h> usw. nicht gefunden. Hat jemand eine Idee, woran das liegen kann?

[MFK]

Das liegt daran, dass das schlicht und einfach falsch ist. Die Header der C++-Standardbibliothek haben kein ".h": <iostream> und <string> sind richtig.

[moehrle]

Hallo, hane nun in der "stdafx.h" dir Headerdateien ohne .h eingefügt. LEider bringt dann der Compiler immer noch die Fehlermeldungen, wenn ich <iostream> einfüge. Er sagt, "cin" und "cout" sind nicht deklariert. Schreibe ich aber die <iostram.h>, dann motzt er erkann die nicht öffnen.

exceptionbesipiel\stdafx.h(17) : fatal error C1083: Datei (Include) kann nicht geöffnet werden: "iostream.h": No such file or directory

Wer hat dazu Rat???

[LordJaxom]

cin und cout liegen seit 1998 im Namensraum std. Also std::cin und std::cout.

[simon.gysi]

Übrigens gehört das ins C++ Forum.
Simon

[C++ Forumbot]

Dieser Thread wurde von Moderator/in Jochen Kalmbach aus dem Forum C++/CLI mit .NET in das Forum C++ verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

[Nexus]

Wozu benötigst du die vorkompilierten Header (stdafx.h)?

[tippgeber]

Nexus schrieb:

Wozu benötigst du die vorkompilierten Header (stdafx.h)?

Um die Compile-Time zu reduzieren, aber angesichts des Kenntisstands des Threaderstellers kann die Anwendung nicht sonderlich komplex sein.

Es ist übrigens echt ein Phänomen wie lange sich diese Irrglaube hält, ich frage mich ob wir in 10Jahren immernoch solche Threads sehen.

[Nexus]

tippgeber schrieb:

Um die Compile-Time zu reduzieren

Wieso reduzieren sie die Compilezeit? Den eigenen Code muss man so oder so immer wieder kompilieren, wenn er verändert wurde, und eingebundene Bibliotheken sind ja auch vorkompiliert...

Abgesehen davon kann man ja bei komplexeren Programmen den Code auf mehrere Module verteilen und dann nur die veränderten neu kompilieren. Und selbst wenn man alle Übersetzungseinheiten neu kompilieren müsste, bräuchte es schon ein gigantisches Projekt, damit die Compilezeit mehr als 30 Sekunden beträgt.

tippgeber schrieb:

Es ist übrigens echt ein Phänomen wie lange sich diese Irrglaube hält, ich frage mich ob wir in 10Jahren immernoch solche Threads sehen.

Welchen Irrglauben? Dass man <stdafx.h> benötigt?

[unskilled]

moehrle schrieb:

Hallo, habe folgendes Problem. In einer Win32-Konsolenanwendung [...] wird einfach die eingebundene Header-Datei <iostream.h>, <string.h> usw. nicht gefunden.

MFK schrieb:

Das liegt daran, dass das [...] falsch ist. Die Header [...] haben kein ".h": <iostream> und <string> sind richtig.

moehrle schrieb:

[Habs versucht] immer noch die Fehlermeldungen, wenn ich <iostream> einfüge. [...] Schreibe ich aber die <iostram.h>, dann motzt er erkann die nicht öffnen.

Kurz:
A: Wie gehts?
B: So nicht, sondern so...
A: So gings nicht - habs jz auch wieder so, wies scho am anfang nicht ging gemacht, wo du meintest, dass es falsch ist - so gehts aber auch nicht *CONFUSED*

Köstlich - vor allem, wie man dann auch noch irritiert sein kann, wenn es noch immer nicht so geht, wie es schon am anfang nicht ging xD
Sry, musste das noch ma zusammenfassen ^^

Nexus schrieb:

tippgeber schrieb:

Es ist übrigens echt ein Phänomen wie lange sich diese Irrglaube hält, ich frage mich ob wir in 10Jahren immernoch solche Threads sehen.

Welchen Irrglauben? Dass man <stdafx.h> benötigt?

Wahrscheinlich eher, dass die std-Header *.h heißen...

tippgeber schrieb:

Nexus schrieb:

Wozu benötigst du die vorkompilierten Header (stdafx.h)?

Um die Compile-Time zu reduzieren, aber angesichts des Kenntisstands des Threaderstellers kann die Anwendung nicht sonderlich komplex sein.

Ich tipp ja mal auf: das ist standard-mäßig beim projekt erstellen dabei und ich weiß nicht, wo ich suchen soll, um die option zu finden, wo man das deaktivieren kann.

Einfach löschen geht glaube nich - meines erachtens sagt er dann immer, dass man versehentlich vergessen hat, die stdafx.h zu includen...

bb

[tippgeber]

Ja einfach löschen geht nicht, da in der Standardeinstellung mit vorkompilierten Header ein Header mit dem Namen erzwungen wird, aber man kann ihn a) ändern, oder b) einstellen, dass man keinen vorkompilierten Header includieren muss und dem Compiler alles erledigen lassen (mache ich immer), also auch keinen extra header erstellen, wobei es da noch ein paar Kleinigkeiten zu beachten gibt, aber das führt jetzt zu weit.

[Nexus]

unskilled schrieb:

Köstlich - vor allem, wie man dann auch noch irritiert sein kann, wenn es noch immer nicht so geht, wie es schon am anfang nicht ging xD
Sry, musste das noch ma zusammenfassen ^^

Ja, es ist echt interessant, wie sich manche Leute gegen Hilfe richtig sträuben.

unskilled schrieb:

Wahrscheinlich eher, dass die std-Header *.h heißen...

Ja, das scheint einer der Standard-Anfängerfehler zu sein (und zwar einer der hartnäckigen Sorte). Ist sogar noch ausgeprägter als if (x = 3) .
Das Problem ist sicher auch, dass es relativ lange gut geht mit .h als Endung...

unskilled schrieb:

Ich tipp ja mal auf: das ist standard-mäßig beim projekt erstellen dabei und ich weiß nicht, wo ich suchen soll, um die option zu finden, wo man das deaktivieren kann.

Einfach löschen geht glaube nich - meines erachtens sagt er dann immer, dass man versehentlich vergessen hat, die stdafx.h zu includen...

Das scheint mir sehr plausibel, anfangs hatte ich dieses Problem sogar selber

Es gäbe natürlich nachträglich eine Option bei den Projekteinstellungen, aber da schauen Anfänger sowieso nie rein

[Bulli]

Nexus schrieb:

unskilled schrieb:

Wahrscheinlich eher, dass die std-Header *.h heißen...

Ja, das scheint einer der Standard-Anfängerfehler zu sein (und zwar einer der hartnäckigen Sorte). Ist sogar noch ausgeprägter als if (x = 3) .
Das Problem ist sicher auch, dass es relativ lange gut geht mit .h als Endung...

Du tust nur so, oder? Mensch, die Leute benutzen noch Uralt-Tutorials oder Uralt-Bücher. Warum? Weil Geiz angeblich geil ist! Anstatt mal nen aktuelles C++-Lehrbuch zu kaufen...

Nexus schrieb:

Das scheint mir sehr plausibel, anfangs hatte ich dieses Problem sogar selber

Es gäbe natürlich nachträglich eine Option bei den Projekteinstellungen, aber da schauen Anfänger sowieso nie rein

Man kann die PCHs auch bei Projekterstellung abwählen. Natürlich ist die serienmäßige Aktivierung richtig, da nicht jeder immer ein HelloWorld-Projekt anlegt. Außerdem hat es auch nichts mit der Projektgröße zu tun, sondern wie komplex die benutzten Headers sind. Vorallem bei komplexen Template-Libs gibts Compiletime-Ersparnis.

[Nexus]

Bulli schrieb:

Du tust nur so, oder? Mensch, die Leute benutzen noch Uralt-Tutorials oder Uralt-Bücher. Warum? Weil Geiz angeblich geil ist! Anstatt mal nen aktuelles C++-Lehrbuch zu kaufen...

Und? Habe ich mich je dazu geäussert, weshalb dieser Anfängerfehler passiert?

Bulli schrieb:

Außerdem hat es auch nichts mit der Projektgröße zu tun, sondern wie komplex die benutzten Headers sind. Vorallem bei komplexen Template-Libs gibts Compiletime-Ersparnis.

Das scheint mir nicht einleuchtend. Was ist denn der entscheidende Punkt beim Einbinden von <stdafx.h>?

[unskilled]

Das scheint mir nicht einleuchtend. Was ist denn der entscheidende Punkt beim Einbinden von <stdafx.h>?

Das manche Windows-Header sich gegenseitig einbinden wollen und es dann probs gibt?
Siehe winsock(2).h und windows.h und deshalb bestimmte Reihenfolge etc...

Was anderes fällt mir jz nicht so wirklich ein, außer die Geschichte mit der Reihenfolge - aber ich sitz auch nicht an projekten, die aus hunderten von tausenden dateien bestehen mit jeweils millionen von zeilen...

bb

[Nexus]

unskilled schrieb:

Das scheint mir nicht einleuchtend. Was ist denn der entscheidende Punkt beim Einbinden von <stdafx.h>?

Das manche Windows-Header sich gegenseitig einbinden wollen und es dann probs gibt?

Okay, danke. Aber dafür, dass viele Leute die Windows-Header gar nie brauchen, sollte zumindest bei der Projekterstellung bei "Vorkompilierter Header" per Default kein Häkchen sein.

unskilled schrieb:

Was anderes fällt mir jz nicht so wirklich ein, außer die Geschichte mit der Reihenfolge - aber ich sitz auch nicht an projekten, die aus hunderten von tausenden dateien bestehen mit jeweils millionen von zeilen...

Ist bei mir eben auch nicht so. Zudem programmier ich nicht mit der WinAPI...

[unskilled]

Ich mag WinAPI aber ^^

PS: Ich brauch mal nen Hook für die rl-WetterAPI Ists bei euch wenigstens auch viel zu warm? So viel Wasser wie in letzter Zeit hab ich in meinem ganzen Leben noch nicht gebraucht-also zum Waschen ;o)

bb

[drakon]

unskilled schrieb:

Ich mag WinAPI aber ^^

PS: Ich brauch mal nen Hook für die rl-WetterAPI Ists bei euch wenigstens auch viel zu warm? So viel Wasser wie in letzter Zeit hab ich in meinem ganzen Leben noch nicht gebraucht-also zum Waschen ;o)

bb

Hmm. Sorry. Habe bei meiner Wettermaschine den Hebel abgebrochen. Und jetzt hangt er auf "Heiss, wie die Hölle" fest.

[Don06]

Nexus schrieb:

unskilled schrieb:

Das scheint mir nicht einleuchtend. Was ist denn der entscheidende Punkt beim Einbinden von <stdafx.h>?

Das manche Windows-Header sich gegenseitig einbinden wollen und es dann probs gibt?

Okay, danke. Aber dafür, dass viele Leute die Windows-Header gar nie brauchen, sollte zumindest bei der Projekterstellung bei "Vorkompilierter Header" per Default kein Häkchen sein.

Wie schon gesagt, dass ist nicht vorwiegend für den Windows Kram, der geht innerhalb von Millisekunden durch den Kompiler. Wenn du gerade boost zur Hand hast, kannst du ja mal folgende Header einfach nur einbinden, also ungefähr so:

#include <boost/mpl/arithmetic.hpp>
#include <boost/mpl/list.hpp>
#include <boost/lambda/lambda.hpp>
#include <boost/spirit.hpp>

int main() { }

Vorkompilierte Header bewirken da wirklich Wunder. Vor allem wirkt das Intellisense weniger belastet. Ohne vorkompilierte Header behauptet das doch - je nach Laune natürlich - glatt, dass es nichts im Namensraum boost gibt, was es kennt.

Gruß
Don06

[lollol]

drakon schrieb:

unskilled schrieb:

Ich mag WinAPI aber ^^

PS: Ich brauch mal nen Hook für die rl-WetterAPI Ists bei euch wenigstens auch viel zu warm? So viel Wasser wie in letzter Zeit hab ich in meinem ganzen Leben noch nicht gebraucht-also zum Waschen ;o)

bb

Hmm. Sorry. Habe bei meiner Wettermaschine den Hebel abgebrochen. Und jetzt hangt er auf "Heiss, wie die Hölle" fest.

Gibs zu. Es war ein Bug!

[drakon]

lollol schrieb:

drakon schrieb:

unskilled schrieb:

Ich mag WinAPI aber ^^

PS: Ich brauch mal nen Hook für die rl-WetterAPI Ists bei euch wenigstens auch viel zu warm? So viel Wasser wie in letzter Zeit hab ich in meinem ganzen Leben noch nicht gebraucht-also zum Waschen ;o)

bb

Hmm. Sorry. Habe bei meiner Wettermaschine den Hebel abgebrochen. Und jetzt hangt er auf "Heiss, wie die Hölle" fest.

Gibs zu. Es war ein Bug!

Was einer.. Es waren Tausende. Aber dafür gibts ja Insektizide. (Hast du gewusst, dass Kakerlaken schreien? Musst nur ganz genau hinhören. :p )

Vorkompilierte Header bewirken da wirklich Wunder. Vor allem wirkt das Intellisense weniger belastet. Ohne vorkompilierte Header behauptet das doch - je nach Laune natürlich - glatt, dass es nichts im Namensraum boost gibt, was es kennt.

Hmm. Das passiert mir öfters, dass er was nicht kennt und ich zuerst die DB von Intellisense wieder löschen muss, bis ich wieder unterstützung habe.