Fehler bei HelloWindows

ich hab ne Win32Anwendung!!!

MFK

OCC schrieb:

C1010: Unerwartetes Dateiende waehrend der Suche nach der Direktive fuer die vorkompilierte Header-Datei

Schalte die Verwendung vorkompilierter Header in den Eigenschaften der Quellcodedatei ab.

P.S.: Einzelne Ausrufezeichen tun's auch.

OK, jetzt funzt!

Danke!

masterofx32

MichaM. schrieb:

Stimmt ist nicht gerade höflich, man sollte schon die Fehlermeldung bei schreiben.
Aber als eingefleischter sieht man**'s** auch so, ändere folgendes:
[cpp]
return CreateWindowEx( 0,
"WindowClass",
"Hello Windows",
WS_OVERLAPPEDWINDOW |
WS_VISIBLE,
100, 100, 400, 300,
NULL,
NULL,
hInstance,
NULL);
[/cpp]

Also eingefleischter ist man sich doch aber der Gleichheit von NULL und 0 bewusst auch wenn es kein guter Stil ist, NULL zu verwenden, wo keine Pointervariable erwartet wird, oder sehe ich das falsch? (Konnte ich mir jetzt nicht verkneifen, ich bitte um Verzeihung )

#define FALSE   0
#define TRUE    1
#define NULL    0

#define NULL ((void*)0)

Wenn ich sein Beispiel kopiere und compile, kommt:

mingw32 schrieb:

main.cpp:64: warning: passing NULL used for non-pointer argument passing 1 of `
HWND__* CreateWindowExA(long unsigned int, const CHAR*, const CHAR*, long
unsigned int, int, int, int, int, HWND__, HMENU__, HINSTANCE__, void)'

Da er keine Fehlermeldung bekannt gab, und der einzige Fehler dieser Schönheitsfehler war, aber sonst alles ok, blieb mir nur diese Aussage.

Als eingefleischter dem Quellcode vorgelegt wird ohne Fehlermeldung, liest man den Code und erkennt Fehler, darauf geht man dann ein, auch wenn es nur ein Schönheitsfehler ist, den ich weiß ja nicht wie sein Compiler damit umgeht.
Fazit: Mein Posting war eine richtige Reaktion, auch wenn es nicht half, aber das lag ja nicht an mir.

masterofx32

Das ist ja seltsam - Warum wird an manchen Stellen in den Headerdateien NULL als 0 definiert und an anderen als echter Null-Pointer!? Ich dachte, es gäbe nur die 0-Variante. In dem Fall war mein Kommentar natürlich überflüssig und ich hab mich wohl vorschnell dazu hinreißen lassen, vor allem weil ich das Substantiv "Eingefleischter" recht amüsant fand

masterofx32 schrieb:

Das ist ja seltsam - Warum wird an manchen Stellen in den Headerdateien NULL als 0 definiert und an anderen als echter Null-Pointer!? Ich dachte, es gäbe nur die 0-Variante.

Da zwischen sitzt aber noch was:
[cpp]
#ifndef NULL /* wenn NULL noch nicht defined /
#ifdef __cplusplus / wenn _cplusplus definiert wurde dann:
#define NULL 0 /* bekommt NULL die 0 /
#else / wenn aber nicht (sonst) /
#define NULL ((void)0) /* definiere NULL als Zeiger */
#endif
#endif
[/cpp]
wenn ich bei meinem test #define _cplusplus angegeben hätte, gäbe es auch keine Fehlermeldung
Nun das hat er in seinem Code ja auch nicht!

MFK

masterofx32 schrieb:

Das ist ja seltsam - Warum wird an manchen Stellen in den Headerdateien NULL als 0 definiert und an anderen als echter Null-Pointer!?

Der Grund für die unterschiedlichen Definitionen ist, dass in C ein void* implizit in jeden anderen Zeigertyp konvertierbar ist - daher ist es z.B. auch nicht notwendig, den Rückgabewert von malloc zu casten.

In C++ geht das nicht, darum bringt das NULL-Pointer-Makro nichts mehr.

Man muss beim Überladen daran denken, dass NULL in C++ ein int ist. Und dann kann man - um Verwirrungen zu vermeiden - auch gleich 0 schreiben.

MichaM. schrieb:

wenn ich bei meinem test #define _cplusplus angegeben hätte, gäbe es auch keine Fehlermeldung
Nun das hat er in seinem Code ja auch nicht!

Als "Eingefleischter" hättest du erkennen können, dass im Code des OP der Compiler selbst __cplusplus definiert

MFK schrieb:

Als "Eingefleischter" hättest du erkennen können, dass im Code des OP der Compiler selbst __cplusplus definiert

Als jemand der Lesen kann, hättest du es Lesen können das ich eine fehlermeldung erhalte! Aha, hatte ich vieleicht kein C++ projekt, sondern nur C ??
Woher soll ich wissen, wer was für einen Compiler hat und welche Projekteinstellungen.

MFK

MichaM. schrieb:

Woher soll ich wissen, wer was für einen Compiler hat und welche Projekteinstellungen.

Man kann den Compiler an seinen Fehlermeldungen erkennen. Und wenn man weiß, dass dieser Compiler nicht den neuesten C-Standard unterstützt, kann man folgern, dass dieser Code nur C++ sein kann.

MFK schrieb:

Man kann den Compiler an seinen Fehlermeldungen erkennen.
....

Dein Lesen hat Winterpause

ER GAB KEINE FEHLERMELDUNG AN NUR SEINEN CODE, N U R - D E N - C O D E , K E I N E - F E H L E R M E L D U N G.

MFK

MichaM. schrieb:

ER GAB KEINE FEHLERMELDUNG AN NUR SEINEN CODE, N U R - D E N - C O D E , K E I N E - F E H L E R M E L D U N G.

Deine Shifttaste klemmt und deine Leertaste prellt.

Vor deiner Aussage

MichaM. schrieb:

wenn ich bei meinem test #define _cplusplus angegeben hätte, gäbe es auch keine Fehlermeldung
Nun das hat er in seinem Code ja auch nicht!

- und nur auf diese bezog ich mich - gab es einige Fehlermeldungen.

Ich hätte vielleicht schreiben sollen: Als "Eingefleischter" hättest du inzwischen erkennen können, dass im Code des OP der Compiler selbst __cplusplus definiert. Sorry, mein Fehler.

@MFK
Ich hätte beischreiben sollen, wenn ich ein C Projekt habe, aber wie du so schön sagst, als "Eingefleischter" sollte man das erkennen. Man konnte beim Threadstarter ja nicht erkennen was, wie und wie auch immer war.
Wenn ich ein C Projekt habe und #define __cplusplus setzte wird es als C++ Projekt behandelt. Darum gings mir, da sein Code keinen Fehler hatte, ausser diesen, hätte es sein können das es ein C Projekt ist und daher hierbei ein Fehler Auftritt.
Bei mir ist diese Fehlermeldung aufgetreten, da ich es als ein C projekt compilte, da brauchte ich nichts erkennen, den ich wußte es. Verstehst du wie ich das meine.