Precompiled Header - Irgendwas stimmt nicht

Servus Forum,

ich bin hier gerade aus Jux mal wieder etwas am Programmieren, mit Visual C++ als IDE, und habe irgendwie gerade Probleme mit den Headern, vor allem diesem stdafx.h, die ich irgendwie nicht lösen kann.

Folgende Situation : Es gibt eine main.cpp, die includiert "stdafx.h". In die habe ich einfach so ziemlich alles gepackt, was ich in der main.cpp brauche - bis auf <winsock2.h>, die inkludiere ich in der main.cpp direkt

### stdafx.h ####
#pragma once

//Weird stuff

#include "targetver.h" // in der steht nur #include <SDKDDKVer.h>, scheint unwichtig

#define WIN32_LEAN_AND_MEAN // wird einem von dem Kommentar als sinnvoll verkauft
// Windows-Stuff

#include <windows.h>
#include <winsock2.h>
#include "resource.h" // einige ulkige #define's zu Konstanten ( Nie damit beschäftigt )

//C++ Stuff

#include <iostream>
#include <string>

Bis dahin ja nicht das Problem, jetzt will ich allerdings eine Klasse definieren - dazu natürlich entsprechende .h und .cpp Datei : "ChatWindow.h" und "ChatWindow.cpp".

### ChatWindow.h ###

#include <stdafx.h>

class chatWindow {

    // Member und Function-Deklarationen

}

### ChatWindow.h ###

#include "ChatWindow.h"

extern HINSTANCE hInst; // Brauche ich aus der main, weil ich hier unter anderem Fenster erzeugen will

// Bis jetzt nur der Ctor definiert, ist aber für das Problem eh irrelevant

Warning und tatsächlicher Fehler :

" #include ChatWindow.h" : Wird bei der Suche nach Verwendung des vorkompilierten Headers übersprungen "

Error : " Unerwartetes Dateiende während der Suche nach dem vorkompilierten Header. Haben sie möglicherweiße "#include "stdafx.h" vergessen "

Hab ich ja nicht ? ;O Wird doch mit #include "ChatWindow.h" auch inkludiert.
Wenn ich "stdafx.h" explizit inkludiere kommen nurnoch Bockmist-Errors dabei raus.

Was mache ich falsch und wie genau habe ich überhaupt diesen precompiled Header zu verstehen?

Danke schon mal und schönen Abend noch !

Edit : Ups, das sollte in "stdafx.h" -> #include <Windowsx.h> und nicht #include <winsock2.h> heißen.

Also Klassendefinitionen müssen mit einem Semikolon beendet werden.
class xyz { };

Das könnte einen "unerwartetes Dateiende" Fehler erklären.

Gruß

Ups, mein Fehler. Im orginalen ist das Semikolon durchaus gesetzt, es ist somit nicht Ursache für den Fehler. Danke trotzdem ^^

Was passiert denn, wenn du das

#include "ChatWindow.h"

mit in die "stdafx.h" schreibst, und in deiner "ChatWindow.cpp" dann diese inkludierst?

Hier steht übrigens, dass die "stdafx.h" immer als erstes inkludiert werden sollte, um den "Pre-Compiled Header" Fehler zu beheben.

http://www.c-plusplus.net/forum/145575-full

Naja, tue ich ja eig. ChatWindow.h inkludiert stdafx.h direkt und die .cpp-Datei wiederum ChatWindow.h.

Martin Richter

Ich würde raten, dass nur CPP Module die stdafx.h includen sollten. Sonst wird die Kontrolle sehr schwer.

weicher

Sorry Martin

ich würde das viel härter formulieren.

stdafx.h muss auschliesslich und als erster #include in allen *.cpp Dateien inkludiert werden!

In *.h Dateien hat ein #include "stdafx.h" absolut nichts zu suchen!

Herzliche Grüsse
Walter

Oh, das wusste ich gar nicht. Mal wieder was dazu gelernt

Das Problem ist jetzt so weit gelöst, allerdings bekomme ich úrplötzlich einen Linker-Error. Ich hab die beiden Dateien, ChatWindow.h und ChatWindow.cpp mal wieder rausgeschmissen, der Linker-Error bleibt aber, sollte also mit dem ganzen stdafx.h-Kram nichts zu tun haben.

Ich habe aber eigentlich 0 in den Projekteinstellungen geändert, also weiß ich nicht was auf einmal das Problem sein soll. Folgender LNK-Error :

error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "_WinMain@16" in Funktion "___tmainCRTStartup".

Klingt fast so als hätte ich ein Konsolen-Projekt gestartet und er sucht nach entspechenden entry-point, aber ich habe natürlich kein Konsolen-Projekt benutzt sondern eine Win32 Anwendung. Habe ja auch schon 100 mal compiled und Fenster erzeugt, etc. . Nun auf einmal meckert der Linker.

Was könnte plötzlich die Ursache sein?

Martin Richter

Nein! Du hast eine Windows Applikation erzeugt, aber keinen Entry Point.

Ist das eine MFC Anwendung?
Dann hast Du kein CWinApp Objekt!

weicher

Welches Visual Studio hast Du?

Bei VisualStudio 2010 ist das Win32 Project eine:
Win32 Application, console application, DLL oder static library

Es kommt jetzt genau darauf an welche optionen Du im Project Wizard angegeben hast.

Wenn Du fensterln willst würde ich Dir sowieso zu MFC Application raten. Beim Wizard auf der ersten Seite auf Single document stellen und dann Finish drücken.

Single document ist für den Einstige etwas einfacher als Multiple documents.

Dann das neu erstellte Projek kompilieren und starten. Wenn alles läuft suchst Du die [Projekt].cpp (Wenn das Projekt "Gugus" heisst, dann Gugus.cpp) darin suchst Du die Funktion InitInstance () und setzt auf dem ersten Statement in InitInstance einen Breakpoint. Dann startest Du den Debugger und schaust wie das Dingens funktioniert. Wenn Du alles verstanden hast, dann kannst Du eigenen Code zum Projekt hinzufügen.

Herzliche Grüsse
Walter

@Martin : Doch ! Habe ich. In meiner Haupt-c.pp Datei befindet sich das übliche int APIENTRY WinMain() bla gedöns. Ich habe ja auch wie gesagt schon 100 mal compilt und den Output betrachtet, etc. Ich weiß nicht, was auf einmal passiert ist ;E

@ Weicher : Jop, ich benutzt VS 2010. Beim Erstellen des Projektes hatte ich Win32 Application angegeben, was auch bis dato funktioniert hat und die richtige Einstellung war.

Mit MFC habe ich mich noch nie beschäftigt, weil mir da Konzept der WinApi irgendwie gefällt Auch wenn es manchmal für das Konzept von C++ an sich nicht ganz geeignet ist - C-Api eben. Aber trotzdem ^^

So, da ich nun wieder da bin und sehe, dass das Problem eig. fast unmöglich durch Beschreibungen zu Erötern ist : Wäre villeicht jemand dazu bereit, sich das Projekt eben über Teamviewer anzuschauen, um so eventuell das Problem zu ermitteln ? So könnte sich derjenige halt direkt anschauen, wie die Projekt-Settings sind etc. und so eventuell leichter auf das Problem kommen

Wäre echt sau nice

Naja, schade. Dann schau ich mal ob ich per Zufall drauf komme

Jemand hat mir heute beim über die Schulter schauen die Lösung auf das Problem gegeben. Statt _tWinMain ( ... ) einfach WinMain(). Das hätte ich nie gedacht, da a) das erstere der Standardname der durch die IDE vergeben wurde war ( okay, ich hab Unicode auf Multibyte geändert - aber siehe b) ) und b) ich folgendes mal im Netz gelesen habe :

_tWinMain is just a #define shortcut in tchar.h to the appropriate version of WinMain.

If _UNICODE is defined, then _tWinMain expands to wWinMain. Otherwise, _tWinMain is the same as WinMain.

Für meinen Fall aber absolut nicht zutreffend. Der Linker hat sich einfach nicht zu dieser Tatsache überreden lassen und ich war lange ratlos. Neue Projekte angelegt, Fehlermeldungen vergleicht, Code bis auf _tWinMain reduziert, etc. etc. . Immer der selbe Fehler.

Hat mich echt gewundert, dass das jetzt des Fehlers Lösung war