[ODE] Another question about header files and linking stuff

[skjold@cistron.nl]

> <skjold@cistron.nl> skreiv:
> 
> > > Why can't I access GL functions from within test_buggy.cpp? I'm playing
> > > a little around with it, and when trying to add my own code to make GL
> > > display a polygonal mesh, I just get "implicit declaration of..".
> 
> > Maybe you forgot to include the gl.h (or glu.h) header in your own program?
> 
> But drawstuff has already included this, and uses these functions? I
> can't include them again in my own program, that gives me more obscure
> messages. 

Yes, gl.h is included in drawstuff.cpp, but not in drawstuff.h. If you include drawstuff.h in your program you still need to include gl.h as well. I suspect that you get these "implicit declaration" errors because you compile drawstuff.cpp with the rest of your project. The compiler sees that gl.h is included in drawstuff.cpp, and thus it knows those OpenGL api declarations, but they aren't considered valid anymore when compilation of your program starts: Thus, you rely on drawstuff to declare the OpenGL api implicitly for your program. Hence, implicit declaration.

This is not a valid situation, you should include gl.h in your program as well. If this results in errors, then you probably don't guard your headers against multiple inclusion, which is basically the opposite problem (gl.h is most likely properly guarded against that). To guard your header against multiple inclusion, just enclose it in a #define like this:

#ifndef _MYHEADER_H_ /* Use some unique name that resembles the name of your header file */
#define _MYHEADER_H_

/* ... put the rest of your header stuff in here

#endif

This prevents the header file from being processed more than once during a build, which is what you want.


> > > And when
> > > I include my code in drawstuff, my program can't access it anymore..
> 
> > Do you also put declarations for your functions (and structs etc) into drawstuff.h (or into a new header that you include in your program)?
> 
> No.. maybe that's what I'm misunderstanding.. ?

It looks like it ;-) The purpose of header files are to tell the compiler what your functions etc. look like. For example, you know there exists a function that looks - roughly - like this:

void glEnd();

You know this because you read a book or a tutorial or something like that, that explained the OpenGL api to you. It's important for you to know that it exists, but you don't need to know exactly what code is in there to do whatever it does. As long as it works, right? Well, the compiler works in the same way. It knows nothing about OpenGL until it reads about it, and that is what the header files are for. They tell the compiler what to expect. So when you call glEnd() in your code, the compiler doesn't care what it does or how, but it just needs to know that this function exists, what parameters it takes etc.

So, when you look at drawstuff.h, you can see exactly what functions are available for you to use, and the compiler sees that too. That is why you can call those functions from your program (such as dsSimulationLoop). But if you add your own functions to drawstuff.cpp, and you want to use them in your own program, the compiler won't know about those functions unless it sees their description added to the drawstuff.h header file.


> 
> > > I guess I'm misunderstanding something vital, but I'm just testing really,
> > > I plan on writing my own replacement for drawstuff after a while. But
> > > for now, is there a quick and dirty way to do this? Or can anybody
> > > explain what I'm misunderstanding? I'm also unable to access c++ stuff
> > > like <vector>.
> 
> > "Unable to access"... how? What error messages are you getting here?
> 
> Just that it couldn't find the file "vector", if I remember correctly.
> And when I specified the full path, I got lots of syntax and not
> defined- errors from within the vector-file. I guessed the makefile used
> a C-only compiler, which didn't understand the C++ in Vector.

Indeed a C compiler can't compile C++ code. :P


Greets,
Mark