Archief - [PROG]Visual C++ Compileerprobleem met klasses

Ik heb jaren lang fun beleed aan het C++ programmeren voor DOS met de Allegro library, maar een mens moet met zijn tijd mee, en hier ben ik dan, verwoede pogingen aan het doen om deftig voor Windows te programmeren.

Momenteel zit ik echter hopeloos vast en ik denk dat het iets heel doms is dat ik over het hoofd zie:

Ik werk momenteel met Visual C++ 6.0, ik heb mijn eerste eenvoudige probeersel met directX klaar. Dit probeersel werkt zonder compileer of runtime problemen . Nu wilde ik uiteraard wat groter gaan, en probeerde een klasse te schrijven, en het is daar dat ik vast loop.

Ik heb vanuit de "Class view" de wizard geopend voor het aanleggen van een nieuwe klasse. Deze heb ik zeer origineel "DOG" genoemd, en uiteraard niet van een andere klasse afgeleid. Visual C++ maakt vervolgens 2 bestandjes, eentje met de klasse definitie, "DOG.h", en eentje met de implementaties "DOG.cpp". De .cpp file komt automatisch bij de source files in de "file view", en de .h file komt automatisch, waar had je het ook verwacht, bij de "header files". In de "Class view" komt de klasse ook te voorschijn en kan je ook de constructor en destructor zien. Om de klasse toch iets te laten doen had ik ze één lidvariabele, namelijk de "int age" meegegeven (waarde wordt in constructor geïnitialiseerd).

Ik compileer het project nog eens en HUP, alles wunderbahr, geen enkele compileerfout.

Dan probeer ik echter om in de WinMain ook daadwerkelijk een DOG te creëren met de magische code

DOG Bobby;

Een poging dit te compileren levert echter volgende error melding:
error C2065: 'DOG' : undeclared identifier

Blijkbaar was de klasse DOG op dat punt tijdens het compileren nog niet gekend/geregistreerd. In een wanhoopspoging heb ik aan het begin van het .cpp bestand met de winmain erin #include "DOG.cpp" gezet. Dit leidt echter enkel tot nog lelijkere foutmeldingen bij het compileren:

Gameframe.obj : error LNK2005: "public: __thiscall DOG:OG(void)" (??0DOG@@QAE@XZ) already defined in DOG.obj
Gameframe.obj : error LNK2005: "public: virtual __thiscall DOG::~DOG(void)" (??1DOG@@UAE@XZ) already defined in DOG.obj
Debug/gameframe.exe : fatal error LNK1169: one or more multiply defined symbols found

Klik om te vergroten...

Hieruit denk ik dan af te kunnen leiden dat de compiler op dit punt de DOG klasse al WEL kent...

Er is waarschijnlijk hiel evidents dat ik over het hoofd zie, maar ik zit er momenteel wel hopeloos mee vast. ad:

Kan iemand me hier uit de nood helpen?

Thx,

Ward.

Je moet headers includen, niet cpp files
dus:
#include "dog.h"

Waarom? De header beschrijft de interface van de klasse en de cpp file implementeert die (in dit geval). Je kan maar 1 implementatie hebben, vandaar dat de compiler daarover kloeg.
Hoe de interface beschreven wordt(in de header dus) kan je overal in je code includen waar je zo'n interface nodig hebt.

Wat de compiler echt zegt is:
"Tijdens het compilen van Gameframe.cpp kom ik de tweede keer een Dog implementatie tegen. Deze is reeds geimplementeerd in DOG.cpp"
(een .obj file is een gecompileerde versie van een .cpp file)

Eternal gratitude! Het is inderdaad daar dat het fout liep.

Ik begrijp echter nog niet helemaal wat er gebeurt. In DOG.cpp staat er #include "DOG.h", maar in DOG.h staat er geen enkele link naar de implementaties in de .cpp file.

Mijn vraag is dan hoe de compiler weet waar hij de imlplementaties moet vinden als ik enkel naar de .h file verwijs? (zoekt de compiler naar een .cpp bestand met dezelfde naam?)

Annyway, voorlopig kan ik weer voort en daar ben ik je heel dankbaar voor.

Kr0meel zei:

Eternal gratitude! Het is inderdaad daar dat het fout liep.

Ik begrijp echter nog niet helemaal wat er gebeurt. In DOG.cpp staat er #include "DOG.h", maar in DOG.h staat er geen enkele link naar de implementaties in de .cpp file.

Mijn vraag is dan hoe de compiler weet waar hij de imlplementaties moet vinden als ik enkel naar de .h file verwijs? (zoekt de compiler naar een .cpp bestand met dezelfde naam?)

Annyway, voorlopig kan ik weer voort en daar ben ik je heel dankbaar voor.

Klik om te vergroten...

Nee, maar de linker (het programma dat de verschillende gecompileerde stukken samenvoegt) wel.

Graag gedaan ^^
En inderdaad: de beschrijving van zo'n interface in een header zegt niet meer dan "als je alles gecompileerd hebt, dan is er ergens in die data (in die .obj bestanden) een implementatie van die klasse zoals hier beschreven staat"
Je kan dus meerdere keer zo'n interface omschrijven(in een header of elders) of deze in verschillende cpp files includen, dat geeft geen compileerfouten die zeggen dat hij al elders beschreven staat.

Succes met coden

Dank dank,

Mijn inzichten in wat de compiler doet zijn bij deze weer iets dieper geworden. Wat het coden betreft twijfel ik nu tussen 3 projectjes:

1) Een AI die GO kan spelen op een deftig niveau (www.gofed.be).
2) Een eigen kleine 3D engine.
3) Een kruising van UT, worms en GTA: top down shooter met over the top wapens en volledig vernielbare omgeving, gefocusd op multyplayer.

Voor 2) en 3) kan ik het één en het ander van m'n oude DOS projecten overnemen, het 1e projectje zal van nul moeten komen.

Wat denk je dat uit didactisch oogpunt interessant zou zijn?

Kr0meel zei:

Dank dank,

Mijn inzichten in wat de compiler doet zijn bij deze weer iets dieper geworden. Wat het coden betreft twijfel ik nu tussen 3 projectjes:

1) Een AI die GO kan spelen op een deftig niveau (www.gofed.be).
2) Een eigen kleine 3D engine.
3) Een kruising van UT, worms en GTA: top down shooter met over the top wapens en volledig vernielbare omgeving, gefocusd op multyplayer.

Voor 2) en 3) kan ik het één en het ander van m'n oude DOS projecten overnemen, het 1e projectje zal van nul moeten komen.

Wat denk je dat uit didactisch oogpunt interessant zou zijn?

Klik om te vergroten...

Misschien is het handig om eerst gewoon goed te leren programmeren alvorens ingewikkelde dingen te gaan maken?

GO is - meen ik me te herinneren - een spel dat niet op 100% analystisch gebaseerde regels kan gespeeld worden. Bij schaken kan dat wel, daar kan je bvb bestaande games analyseren en kijken wat de slimste zet is, bij GO ligt dit veel complexer.
Er is niet iets als "een kleine 3D engine", want er komt altijd veel bij kijken (als je het ook nog maar ietwat bruikbaar wil maken). Mijn kleine 3D engine is binnen 2 weken 4 jaar in ontwikkeling, go figure
UT, Worms en GTA mengen klinkt ook niet als een klein projectje.

Waarom niet eerst alles goed onder de knie krijgen alvorens zo'n groot projecten te beginnen?

maak eerst pong, dan pacman of zo, dan ... . De meeste gameprogrammeurs gaan door een dergelijke cyclus hoor (hoewel je hun creaties nooit ziet gepubliceerd worden aangezien deze itt vele flash-ontwikkelaars vaak beseffen dat deze games gepatenteerd zijn <_<).

Hij kan al programmeren vich, is enkel aan het hervatten , staat in zen eerste post .

Het wordt teveel voor kr0meel! (kon het niet laten )

Mijn eerste test was een 3D terrain engineke, als je weet wat je wilt kan je de scope beperken en toch veel bijleren hoor. Doe gewoon waar je t meeste zin in hebt!

Thanx guys.

Ik zal er nog eens over denken hoor . Het domme is dat ik nu weer worstel met de heel basic dingen. Hoe krijg ik een klasse deftig gecompileerd, hoe moet ik input afhandelen, hoe teken ik een lijn....
En dat terwijl ik mijn hoofd voorheen brak over hoe ik de FPS in m'n kleine 2D en 3D engines omhoog kon krijgen en hoe ik de collisie detectie zou implementeren.

Het leven kan vreemd zijn