[C++] OpenGL include probleem

[JayVee]

Hey!

Ik ben al langer bezig uit interesse een 3d engine te schrijven. Na een leuke software renderer in Java ben ik nu bezig met een OpenGL renderer in C++.

Ik heb diverse ebooks en een boek over C++ gelezen. Ook de GoT FAQ heb ik bekeken. Nu zit ik echter nog steeds met een

Probleem / vraag:
Ik snap nog steeds niet hoe je includes moet structureren. Wat is het "algoritme" met die je includes moet schrijven?

Op dit moment doe ik het zo:
In mijn header files include ik andere (eigen / library) headers die ik nodig heb voor de declaraties. In de source file include ik de bijbehorende header (duh) en andere libraries die ik nodig heb voor de definities (zoals string of math).

Een voorbeeld:

C:

// modelmaker.h :
#include <gl\gl.h>  // Header File For The OpenGL32 Library

bool loadGLTexture ( char*, GLuint* );


// modelmaker.c :
#include <fstream>      // for opening files
using namespace std;
#include "modelmaker.h" // my header

bool loadGLTexture ( char* filename, GLuint* texture ) {
    file = fopen( filename, "r" );      // open file
}

Ik gebruik "include guards" om niet dubbel te includen.

In het voorbeeld hierboven heb ik al een probleem:
gl.h maakt gebruik van WINDGIAPI en de declaratie daarvan "krijg" je alleen als je <windows.h> include. Overal dus maar windows.h includen lijkt mij nou echt geen mooie oplossing (maar misschien moet het wel?).

Voor de grap heb ik dat wel even gedaan. Krijg ik ineens 100 compile errors omdat hij "fout" niet kent... rare zooi dus...


De source code en met MS VS project kan je hier downloaden! Models kan ik er helaas niet bijzetten aangezien daar copyright van id software op rust! (ik gebruik models uit Doom³ om te testen! )

[EfBe]

altijd includes boven in je file, en altijd #ifndef... blabla er omheen. Je krijgt dan alleen problemen met cyclic references maar ook daar is een mouw aan te passen (3e includefile).

[JayVee]

EfBe schreef op 22 februari 2004 @ 18:44:
altijd includes boven in je file, en altijd #ifndef... blabla er omheen. Je krijgt dan alleen problemen met cyclic references maar ook daar is een mouw aan te passen (3e includefile).

Ik zet de includes inderdaad helemaal bovenaan. En ik had in de startpost al gezegd dat ik include guards gebruik.

En wat bedoel je met een 3e include file? Een file met includes die de meeste source files wel nodig hebben?

[Verwijderd]

Over het algemeen kun je stellen: Gebruik includes alleen daar waar echt nodig. Pas vooral op met includen bovenin header files. Zo even uit mijn blote bolletje moet je in header files alleen includen (laten we zeggen voor class A) als je:
1) non-pointer class members van type A hebt
2) erft van A

Kan zijn dat ik wat vergeten ben, maar probeer altijd zoveel mogelijk met forward declarations te werken. Word je compileren ook sneller van. Als je de details wil weten moet je es Large-Scale C++ Software Design van John Lakos bekijken.

[MSalters]

Verwijderd schreef op 22 februari 2004 @ 20:07:
Over het algemeen kun je stellen: Gebruik includes alleen daar waar echt nodig. Pas vooral op met includen bovenin header files. Zo even uit mijn blote bolletje moet je in header files alleen includen (laten we zeggen voor class A) als je:
1) non-pointer of non-reference class members van type A hebt
2) erft van A

3) in een inlined functie A gebruikt (op de stack zet, A* dereferenced, etcetera)
4) A in een exception specification hebt

[JayVee]

Hey! Ik heb weer wat tijd om aan de engine te sleutelen (tentamenweek he! ) maar ik kom er gewoon niet uit!

Als ik in de header van loadmodel.h deze regel heb staan:

C:

bool loadGLTexture ( char*, GLuint* );

Dan heb ik GLuint nodig. Als ik nu echter gl\gl.h include krijg ik deze foutmelding:

C:

c:\program files\microsoft visual studio\vc98\include\gl\gl.h(1152) :
        error C2144: syntax error : missing ';' before type 'void'
c:\program files\microsoft visual studio\vc98\include\gl\gl.h(1152) :
        error C2501: 'WINGDIAPI' : missing storage-class or type specifiers

// regel 1152 van gl.h:
WINGDIAPI void APIENTRY glAccum (GLenum op, GLfloat value);

WINGDIAPI wordt weer gedefineerd in windows.h

Nu is het toch niet de bedoeling dat ik maar windows.h ga includen in elke file die GLuint (of andere declaraties van gl) nodig heeft?

Is het in dit geval wel nodig om gl.h te includen? Als ik naar de tips van Ash en MSalters kijk lijkt mij van niet: gl.h bevat geen classes (mijn code ook niet), ik gebruik geen inline functies of exceptions.

Maar hoe zorg ik er dan voor dat hij weet wat GLuint is?

// edit: gl.h en windows.h worden trouwens al in andere files geinclude... kan ik daar dan nie gebruik van maken?

[ Voor 10% gewijzigd door JayVee op 10-03-2004 22:10 ]

[.oisyn]

Je zou ook gewoon niet de opengl defines kunnen gebruiken

[Verwijderd]

waarom zou je niet gewoon windows.h includen ?

[JayVee]

@ .oisyb:
Dus ipv "GLuint" gewoon "unsigned" schrijven? Kan, maar lijkt mij nou niet de juiste manier om het te doen. Daarnaast wil ik niet alleen dit probleem oplossen maar gewoon weten hoe je dit soort zaken doet.

@xerix:
Dat kan natuurlijk. Lijkt mij echter ook niet de bedoeling. Ash zei ook al dat je zo weinig mogelijk moet includen.

Maar hey, als altijd alles includen nou eenmaal "de manier" is om in C++ te coden dan doe ik dat!

Is het niet mogelijk om (bijvoorbeeld) GLuint een keer te includen en dan globaal te defineren?

[.oisyn]

JayVee schreef op 10 maart 2004 @ 22:26:
@ .oisyb:
Dus ipv "GLuint" gewoon "unsigned" schrijven? Kan, maar lijkt mij nou niet de juiste manier om het te doen.

Mwoa, ik zie niet echt een probleem. Het is ook niet dat je overload-problemen krijgt omdat het allemaal C functies zijn die niet eens geoverload kunnen worden.

Daarnaast wil ik niet alleen dit probleem oplossen maar gewoon weten hoe je dit soort zaken doet.

In het algemeen moet je ervoor zorgen dat je headers zo min mogelijk dependencies hebben. In het geval van de platform SDK headers is dat idd een beetje een probleem

Is het niet mogelijk om (bijvoorbeeld) GLuint een keer te includen en dan globaal te defineren?

Je zou dit rijtje op kunnen nemen in een aparte header die je include als je niet gl.h wilt includen

C++:

typedef unsigned int GLenum;
typedef unsigned char GLboolean;
typedef unsigned int GLbitfield;
typedef signed char GLbyte;
typedef short GLshort;
typedef int GLint;
typedef int GLsizei;
typedef unsigned char GLubyte;
typedef unsigned short GLushort;
typedef unsigned int GLuint;
typedef float GLfloat;
typedef float GLclampf;
typedef double GLdouble;
typedef double GLclampd;
typedef void GLvoid;

[JayVee]

Okay. Ik schrijf gewoon de nodige typedefs in de in headers van de source files die ze gebruiken.

Bedankt voor alle tips. Goh wat is Java toch makkelijk! 8 )

// edit:
Nou, een vraagje dan nog:
Als je al moet includen, en je hebt het pas in de source file nodig. Is het dan ook beter hem daar te includen? Of kan je beter alle includes in de headers zetten?

.oisyn, je zegt dat je dependencies in headers moet vermijden. Kan je dat doen door in de source file te includen?

[ Voor 51% gewijzigd door JayVee op 10-03-2004 23:01 ]

[JayVee]

Zucht. GL geeft nu geen problemen meer. Nu heb ik echter nog steeds een probleem met includen.

In de header world.h defineer ik structs mesh en model.

Deze gebruik ik in andere source files. Maar al include ik world.h (in header of source), dan zegt hij nog "undeclared identifier"

Natuurlijk kan ik ze overal declareren (zonder de defineren uiteraard), maar is dat de bedoeling / nodig?

[Verwijderd]

Ik zou gewoon een model.h maken met de definitie van je model struct en deze includen waar nodig.

[JayVee]

Maar wat is dan het verschil met het struct in world.h te defineren en world.h te includen waar nodig?

[Verwijderd]

opzich geen verschil alleen het is wat netter imho

[.oisyn]

JayVee schreef op 10 maart 2004 @ 23:07:
Deze gebruik ik in andere source files. Maar al include ik world.h (in header of source), dan zegt hij nog "undeclared identifier"

Dan doe je denk ik iets fout. Kun je een stukje code geven?

[JayVee]

Hm, okay.

Whatever, had een foutje in world.h en daarom las hij natuurlijk ook de structs niet goed in. Nu werkt het allemaal!
Als mensen de source nog willen zien wil ik hem best nog eens op mijn webspace zetten trouwens.


Een laatste vraag:
Ligt het aan mij of is het werken met headers en include's gewoon lastig en moeilijk in C(++)?

//edit:
Oh ja, en deze vraag staat nog open:

JayVee schreef op 10 maart 2004 @ 22:55:
Als je al moet includen, en je hebt het pas in de source file nodig... Is het dan ook beter hem daar te includen? Of kan je beter alle includes in de headers zetten?

//edit 2
Jullie kunnen hier een screenshot van de engine bekijken!

//edit 3
Vooruit dan maar. Hier kan je de source, het MS Visio project, de exe en de data (models, textures) downloaden!


while ( true )
thx();

[ Voor 57% gewijzigd door JayVee op 11-03-2004 00:05 ]

[.oisyn]

JayVee schreef op 10 maart 2004 @ 23:41:
Ligt het aan mij of is het werken met headers en include's gewoon lastig en moeilijk in C(++)?

ik denk het, want ik heb er nooit echt problemen mee

Nou, een vraagje dan nog:
Als je al moet includen, en je hebt het pas in de source file nodig. Is het dan ook beter hem daar te includen? Of kan je beter alle includes in de headers zetten?

Uiteraard, een header bevat declaraties en definities. Alles wat je in een header moet includen is datgene wat voor de declaraties en definities in die header nodig is, niet voor de sourcefile wat toevallig die header include. Je maakt een header ook niet voor een bepaalde sourcefile, je maakt een header juist voor alle andere sourcefiles die de code uit die ene sourcefile willen kunnen gebruiken.

.oisyn, je zegt dat je dependencies in headers moet vermijden. Kan je dat doen door in de source file te includen?

als de header die je moet includen nog niet nodig is in een andere header dan moet je 'm ook niet in die andere header includen natuurlijk he