Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Problem mit Listing 2.19 !

  • 1
  • 2

Werbeanzeige

thexray

Frischling

  • »thexray« ist der Autor dieses Themas

Beiträge: 12

  • Private Nachricht senden

1

15.04.2004, 18:39

Problem mit Listing 2.19 !

Hallo,

die ersten zwei Programme zum auslesen und ausgeben der
Adapterinfos hab ich selber nachgeschrieben und habs letztendlich
auch zum Laufen gebracht, nun habe ich aber ein Problem mit
dem "Fenster"-Programm.

Wenn ich den Workspace von der CD in Visual C++ 6.0 lade
und BUILDE, klappt alles, nur beim selber nachschreiben nicht.

Ich habe einen neuen Workspace angelegt (Win32APP, new C++ Source File), die Datei TribaseD.dll gelinkt und mal alle Dateien aus dem RES Verzeichnis von der CD in mein Projekt-Verzeichnis kopiert, wie auch
die InitWindow.h und .cpp.

Es kommt die Fehlermeldung:

--------------------Configuration: fenster - Win32 Debug--------------------
Linking...
main.obj : error LNK2001: unresolved external symbol "enum tbResult __cdecl ExitWindow(void)" (?ExitWindow@@YA?AW4tbResult@@XZ)
main.obj : error LNK2001: unresolved external symbol "enum tbResult __cdecl InitWindow(int,int,char *,struct HICON__ *)" (?InitWindow@@YA?AW4tbResult@@HHPADPAUHICON__@@@Z)
Debug/fenster.exe : fatal error LNK1120: 2 unresolved externals
Error executing link.exe.
Creating browse info file...

fenster.exe - 3 error(s), 0 warning(s)

..................
hier mein .cpp File:
..................

#include <Windows.h>
#include <TriBase.h>
#include "InitWindow.h"
#include "Resource.h"

tbResult Render(float fNumSecsPasses)
{
return TB_OK;
}


tbResult Move(float fNumSecsPasses)
{
return TB_OK;
}



int WINAPI WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
char* pcCmdLine,
int iShowCmd)
{
tbInit();

InitWindow(640, 480, "Screen Creation v0.1",
LoadIcon(hInstance, MAKEINTRESOURCE(IDI_ICON1)));

tbDoMessageLoop(Render, Move);

ExitWindow();

tbExit();

return 0;
}




Vielleicht weiss ja jemand woran das liegt ?

Die Files von der CD builden ist easy, aber das nützt mir nichts,
wenn ich nachher nicht selber was mit eigenem Workspace hinbekomme.
Wie gesagt, das mit der Adapterabfrage hat funktioniert.


Vielen Dank schonmal !

Ralph

ps: hatte das ganze ausversehen noch in ein anderes Forum gepostet, sorry !

Triac

Treue Seele

Beiträge: 199

  • Private Nachricht senden

2

15.04.2004, 18:41

hast du auch die InitWindow.h Datei in diesen Ordner eingefügt ???
/Acer Aspire 5920

thexray

Frischling

  • »thexray« ist der Autor dieses Themas

Beiträge: 12

  • Private Nachricht senden

3

15.04.2004, 18:56

hi triac, danke für die schnelle antwort !

ich hab nun nochmal per hand (ohne suchfunktion) in den foren gesucht
und hab rausgefunden, dass ich die datei InitWindow.cpp Datei in mein Projekt (in Visual c++ 6.0) zu den Source Files adden muss.

Nun klappt es komischerweise.

Ich dachte, dass durch den Befehl #include "InitWindow.h" automatisch die
Datei InitWindow.cpp mitbenutzt werden kann ?!

Soweit ich das mitbekommen habe ist eine Header Datei doch dazu da,
Funktionen einer CPP Datei zu deklarieren oder hab ich das irgendwie
falsch verstanden ?

2. noch ne Frage, wieso brauche ich nach dem Builden auch noch die
Tribase.dll Datei im Startverzeichnis der Fenster.exe ?
Kann ich nicht auf einfache Art und Weise nur das nötigste aus der Tribase.dll in die EXE mitreinpacken so dass die DLL Datei nicht mehr
zum ausführen benötigt wird ?

Auf der CD ist die fertige Fenster.exe ohne die DLL Datei ausführbar,
die neue gebuildete im Release Verzeichnis allerdings nicht !

Vielen Dank nochmal !

Ralph

Triac

Treue Seele

Beiträge: 199

  • Private Nachricht senden

4

15.04.2004, 19:35

also . . .

zu 1)

da InitWindow.h keine Standardheaderdatei ist muss ein Verzeichnis angegeben werden:
"myfunctions.h" . . . sobald man die Headerdatei selbst erstellt muss man auch den Pfad angeben, in diesem Fall hast du den Ordner in dem dein InitWindow.ccp ist angegeben.
wenn du um ein paar Ordner hinaufspringen willst so musst du das ganze folgendermaßen angeben:

#include "..\\..\\Allgemeines\\InitWindow.h" (wie in Davids Bsp im Buch)

zu 2)

darauf kann ich leider nicht antworten
(bin selber erst ein "blutiger Anfänger")
ich denke schon, dass es möglich ist aber ich glaube es wurde vermieden um die Engine unabhängig von der exe zu haben (siehe Buch dynamische Engine Seite 21)

puh ich glaub das wars
;D
Mfg. Triac
/Acer Aspire 5920

thexray

Frischling

  • »thexray« ist der Autor dieses Themas

Beiträge: 12

  • Private Nachricht senden

5

16.04.2004, 01:19

hmm.. also die InitWindow.h Datei (wie auch die .cpp) hab ich sowieso
in mein Projekt-Verzeichnis kopiert, deswegen keine Pfadangabe.

zu 2. das denk ich mir auch. das ist dann wohl gleichbedeutend damit,
dass kein besonderer anlaß für den autor bestand, aufzuzeigen,
wie man dll-unabhängige .exe dateien buildet. ;)

kann ich ihm nicht verübeln, aber mich würde es trotzdem interessieren.
ich klau auch nicht. :) (alter codercodex)

ich find das buch lässt noch einige fragen offen, besonders zu header dateien. in der initwindow.h steht ja z.b. ganz oben ne info dazu, was
die header datei macht, allerdings steht nicht beschrieben, wozu der
abschnitt mit dem

#ifdef _INITWINDOW_CPP
#undef VAR
...

gut sein soll.

wär für ihn bestimmt keine große sache gewesen, den sinn bzw.
ne logische erklärung dazuzuschreiben.

man kann sichs zwar denken aber wozu nun das _ zeichen vor dem initwindow und anstatt nem . vor dem cpp steht und was VAR für
ne bedeutung hat..

das ganze sagt mir als nichtswisser nur soviel:
wenn _initwindow_cpp (was auch immer das sein soll) definiert ist, dann
soll er ne variable definieren ansonsten angeben, dass sich diese datei (?)
extern befindet..

aber solche schlussfolgerungen bringen mir im endeffekt ohne zuwissen wofür VAR steht und was das ganze wirklich bedeutet nicht viel...

naja, aber dafür braucht man wohl ein c++ buch.

ich glaube zu merken, dass es dem autor wohl oft gar keinen spass gemacht hat, alles sooo ausführlich über c++ zu erläutern ;) und er
auch ne ganz klare grenze hatte, was für das thema das buches bzw.
das thema directx9-programmierung mit generierung einer engine
notwendig ist.

aber weiss vielleicht trotzdem jemand was zu dem abschnitt in der
InitWindow.h Datei und wieso die InitWindow.cpp nicht automatisch
gefunden wird ??

liegt das vielleicht am Visual C++ Compiler ?

Danke !

Ralph

Triac

Treue Seele

Beiträge: 199

  • Private Nachricht senden

6

16.04.2004, 13:02

wieeso die InitWindow.ccp ich dachte die InitWindow.h ???

...die Include und Bibliotheksdateien werden doch in den Programmoptionen "Verzeichnisse eingebunden"

das mit dem _ weiß ich leider nicht.

aber das

#ifdef _INITWINDOW_CPP
#undef VAR

hat glaube ich etwas mit einer Klasse zu tun

bin im Buch selber erst beim Initialisieren des Fensters (schon seit 2 Wochen)
ich hänge hier einfach . . . weiß nicht warum aber es ist so

Mfg. Triac
/Acer Aspire 5920

Osram

Alter Hase

Beiträge: 889

Wohnort: Weissenthurm

Beruf: SW Entwickler

  • Private Nachricht senden

7

16.04.2004, 14:24

Kleiner Denkanstoss, habe nicht zu mehr Zeit:

Sagen wir, Du machst ein neues projekt in MSVC und hast nur eine C++ Datei drin und die enthält:

MeineFunktion(10);

MeineFunktion sei "irgendwo draussen" definiert, d.h. z.B. in einer Bibliothek.

Der C Compiler kann u.a. nicht wissen, welche Parameter MeineFunktion hat, also mekert er. Du fügst nun die Header Datei mit der Zeile

void MeineFunktion(int a, int b);

hinzu. Der Compiler mekert jetzt das ein Parameter fehlt, also fügst Du den hinzu. Der Compiler ist jetzt zufrieden. Aber der Linker muss jetzt die Adresse von MeineFunktion auflösen, d.h. irgendwoher muss der Computer ja wissen, was MeineFunktion macht. Es wird also der "rumpf" der Funktion benötigt. Dazu brauchst Du direkt oder indirekt die *.cpp Datei. Indirekt ist z.B., wenn Du *.cpp in eine Bibliothek (*.lib oder *.dll) compilierst und dann auf diese zugreifst. Solange Du aber zu nem Standard Projekt nichts hinzufügst, kann der Linker nicht wissen, wie MeineFunktion intern aussieht.

Man könnte hierüber ein ganzes Buch schreiben :-/

Anonymous

unregistriert

8

16.04.2004, 22:55

Zitat von »"thexray"«

die header datei macht, allerdings steht nicht beschrieben, wozu der
abschnitt mit dem

#ifdef _INITWINDOW_CPP
#undef VAR
...

gut sein soll.


also erstmal wollte ich sagen das ich finde David hat schon viel von C++ erklärt in seinem Buch, und als blutiger Programmieranfänger kommt man einfach nicht drumherum auch mal ein Buch nur über C++ zu lesen, ansonsten hätte David ja nochmal 500 Seiten dranhängen müssen....

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11

#ifdef _INITWINDOW_CPP
#undef VAR
#define VAR
#else
#undef VAR
#define VAR extern
#endif

// ******************************************************************
// Variablen
VAR HWND g_hWindow;



also da steht (auf Deutsch ) (nach Zeilen)

1) wenn das "Compiler - Symbol" _INITWINDOW_CPP (hat sich David einfach ausgedacht diesen namen) gesetzt ist (was in initwindow.cpp mit #define _INITWINDOW_CPP passiert) dann

2)nehme vorherige Definitionen von dem "Compiler-Symbol" VAR
zurück (auch VAR ist von David ausgedacht - man könnte auch
XYZ56AeR nehmen)

3)definiere VAR als "" bzw nichts oder leerzeichen oder so.....

4) ansonsten (wenn _INITWINDOW_CPP nicht definiert ist)
5)nehme vorherige Definitionen von dem "Compiler-Symbol" VAR zurück
6) definiere VAR als extern
damit wird überall wo jetzt im Code VAR steht ein "extern" eingefügt
durch den Präcompiler also noch vor dem eigentlichen Compilieren

7) ende der ifdef / else verzweigung

somit kann man überwachen wie " VAR HWND g_hWindow; " vom Compiler verstanden werden soll : einmal nimmt er es als
"HWND g_hWindow;" und einmal als "extern HWND g_hWindow;" je nachdem ob die initwindow.cpp schon ausgeführt und _INITWINDOW_CPP
schon deklariert wurde....

hoffe es ist jetzt etwas klarer geworden....

thexray

Frischling

  • »thexray« ist der Autor dieses Themas

Beiträge: 12

  • Private Nachricht senden

9

17.04.2004, 00:46

ok, das heisst dann also, dass es nur für den compiler interessant ist,
ob er die zeile jetzt compiliert, oder später wenn er die .cpp datei schon
"durchgeschaut hat" und die funktionen aus der .cpp datei benutzen kann ?

hat dieses "extern" ne generelle bedeutung oder ist das auch wieder
von david deklariert ? müsste ja wenns generell gültig wäre, dann eigentlich
ein hinweis für den compiler sein.

oh gott, ich seh schon, ich "stell mich hier an" wie ein totaler depp ;))
der sich noch kein "richtiges" c++ buch durchgelesen hat, aber schon jahre
damit programmiert hat. ;)

vielen dank jedenfalls ! auch wenn ich mit der erklärung nicht selber
eigenständig völlig verstehen werde, von welchem typ VAR z.b. ist, und
für was es gut ist.

das mit dem kommentar zu davids c++ erklärungen war nicht besonders
kritisch gemeint, ich finds eigentlich schon sehr respektabel, wie geordnet
und überdacht die erklärungen geschrieben sind. ich hab mir selber viel
herleiten können dadurch.

aber wie man nun die initwindow.cpp datei ohne diese "blöde" microsoft-visual-c++ overflächen action (bei sources rechtsklick und auf
add source und die cpp datei von hand zum "projekt" dazufügen) hinbekommt, weiss das trotzdem jemand ?

ich hab noch nie viel von so kompletten total verplanten oberflächen
für programmierung gehalten, die alles übersichtlicher und einfacher für
den benutzer machen. ich steh mehr auf texteditor und command line
compiler, maker, linker...

und das muss ja auch mit irgendeiner textzeile im source code klappen,
denk ich mal, dass die initwindow.cpp benutzt werden kann und nicht nur
die header datei mit include, oder ?

vielen dank nochmal und bis bald ! :)

Ralph

Anonymous

unregistriert

10

17.04.2004, 21:14

Zitat von »"thexray"«

ok, das heisst dann also, dass es nur für den compiler interessant ist,
ob er die zeile jetzt compiliert, oder später wenn er die .cpp datei schon
"durchgeschaut hat" und die funktionen aus der .cpp datei benutzen kann ?


NEIN !
Die Zeile wird in diesem beispiel IMMER compiliert,
nur je nach Fall halt anders.....

Zitat

hat dieses "extern" ne generelle bedeutung oder ist das auch wieder
von david deklariert ? müsste ja wenns generell gültig wäre, dann eigentlich
ein hinweis für den compiler sein.


JA
das bedeutet, der Compiler soll die folgende Variable nicht nochmal neu definieren, sondern Sie wurde schon in einer anderen Datei definiert und soll jetzt hier aber so verwendet werden, als sei es eine Variable, die die Datei selber deklariert hat........
also eigentlich ist die Variable "extern".....

Zitat

vielen dank jedenfalls ! auch wenn ich mit der erklärung nicht selber
eigenständig völlig verstehen werde, von welchem typ VAR z.b. ist, und
für was es gut ist.


Was genau verstehst Du denn nicht ?

VAR ist von gar keinem Typ das ist einfach eine Definition im Präcompiler, die mit #define definiert wurde,
Du kannst das so sehen :
Zuerst geht beim Compilieren der Präcompiler den Code durch, überall wo jetzt VAR im Code steht, setzt er das ein, was aktuell als VAR definiert ist, also du könntest auch so machen

#define NAME "Peter"
cout << NAME; // er gibt jetzt -Peter- aus

#define NAME "Hans"
cout << NAME; // jetzt gibt er -Hans- aus..


oder aber auch so :

#ifdefine _DEBUG
#define NAME "Peter"
#else
#define NAME "Hans"
#endif
cout << NAME;

so wird je nachdem ob du im Debug- oder Release-modus das Programm komiplierst beim Start Peter oder Hans ausgegeben.
Kompilierst du im Debug-Modus, definiert MSVC++ automatisch das Symbol _DEBUG...

Hier werden meistens NUR Grossbuchstaben verwendet, damit es sich im Code klar von anderen Variablen, KOnstanten,... unterscheidet. Und oft diese unterstriche ___ damit keine Symbole öfters definiert werden
( ich nehm immer sowas wie _________PROG___CPP___FABSTER)

also ähnlich wie ne Konstante, nur das Sie VOR dem Compilieren ersetzt wird, also zur Laufzeit nicht verändert werden kann, dafür aber auch keinen extra Speicher wie eine Konstante braucht......

Zitat


aber wie man nun die initwindow.cpp datei ohne diese "blöde" microsoft-visual-c++ overflächen action (bei sources rechtsklick und auf
add source und die cpp datei von hand zum "projekt" dazufügen) hinbekommt, weiss das trotzdem jemand ?

Da kann ich leider auch nicht helfen....

Aber wenn du zu oben noch fragen hast, frag einfach ich werds versuchen einigermaßen klar rüberzubringen, ich such auch nochmal ob es da nicht spezielle gute texte im netz zu gibt (sonst guck mal unter "Makros mit C++" oder so....)


p.S: das mit dem c++ Buch war nicht als persönlicher Angriff gemeint, ich hoffe Du hast das jetzt nicht falsch verstanden, ich wollte nur zum Ausdruck bringen, das es halt nicht alles in ein Buch passt..... Ich persönlich zum Beispiel hätte ja gerne was mehr zu mathematischen grundlagen gelesen mit vielen beispielen usw.....aber dazu muss ich mir jetzt halt mal ein MatheBuch in der Uni-Bibliothek holen......

Werbeanzeige

  • 1
  • 2