4. Precompiled Header - Irgendwas stimmt nicht

Precompiled Header - Irgendwas stimmt nicht

  • ?

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

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

    Gruß

    0
  • ?

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

    0
  • ?

    Was passiert denn, wenn du das

    #include "ChatWindow.h"

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

    0
  • ?

    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

    0
  • ?

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

    0
  • Mod

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

    0
  • W

    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

    0
  • ?

    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? 😮

    0
  • Mod

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

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

    0
  • W

    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

    0
  • ?

    @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 ^^

    0
  • ?

    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 😉

    0
  • ?

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

    0
  • ?

    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 😮

    0
Anmelden zum Antworten