Programming Forums > Application Development > C++

Klarre · May 21st, 2006, 10:48 AM

Is it in some way possible to remove the #include <GL/gl.h> line? Can I forward declare GLfloat in some way?

#include <GL/gl.h>
class Foo
{
public:
    Foo();
    ~Foo();

private:
    GLfloat mBar;
};

Thanks for your ideas!

DaWei · May 21st, 2006, 11:25 AM

If you duplicate what GL/gl.h is doing. Why would you want to do that?

Klarre · May 21st, 2006, 11:38 AM

I found an error in my code. It should be:

(Toggle Plain Text)

GLfloat* mBar

Well, actually I was most curious about if it was possible in some way to forward declare data types that are typedefed. The reason is that I want my header file free from dependencies. The GL include file might have been a bad example though...

DaWei · May 21st, 2006, 1:30 PM

Generally speaking, the compiler needs to know enough to emit code that will implement your statement. It may emit that code with temporary entities which will be filled in by the linker (or even at runtime), but those temporary entities must be of the correct form. If you declare a pointer, as in GLfloat* mBar, the compiler knows what size of entity to allow for, because a pointer is a pointer is a pointer (generically speaking, please no one jump on near/far/et.al pointers). At some later time, the compiler is going to need to know what TYPE of pointer that is, just to make sure you didn't goof up in your subsequent usage. This is really more a favor to you than anything else. If you declare a GLfloat, though, the compiler is going to need to have some pattern for that to go by. It could be a twelvety-four byte structure, or something. You get my drift. Include files "go away" before the compiler even comes onto the scene. By that, I mean that the preprocessor essentially copies and pastes the contents of the include file into the source and THEN gives the compiler the whole shebang. If the compiler didn't need that information, there would be no need to include the file. If it does need the information, and it's not available, there's trouble in River City. The preprocessor also expands macros and so forth. Your cute little #defines are not seen by the compiler; the result of expanding them is seen by the compiler. The '#' indicates entities to be dinked with by the preprocessor; they're gone, only their effects remain, in the material the compiler works with. One should have a mental perception of the (at least) three separate operations that take place in going from source code to an executable file: preprocessing, compiling, and linking. There may be a locating step. That may be handled by the system's executive. It varies from system to system and operating system to operating system (if there even IS an operating system worthy of the name).

Klarre · May 21st, 2006, 1:59 PM

Thanks alot for your response, and time! That was what I wanted to know.

/Klarre

May 21st, 2006, 10:48 AM	#1
Klarre Game engine designer Join Date: May 2005 Location: Sweden Posts: 309 Rep Power: 4	Forward declaration... Is it in some way possible to remove the #include <GL/gl.h> line? Can I forward declare GLfloat in some way? (Toggle Plain Text) #include <GL/gl.h> class Foo { public: Foo(); ~Foo(); private: GLfloat mBar; }; #include <GL/gl.h> class Foo { public: Foo(); ~Foo(); private: GLfloat mBar; }; Thanks for your ideas!

May 21st, 2006, 11:25 AM	#2
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	If you duplicate what GL/gl.h is doing. Why would you want to do that? __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

May 21st, 2006, 11:38 AM	#3
Klarre Game engine designer Join Date: May 2005 Location: Sweden Posts: 309 Rep Power: 4	I found an error in my code. It should be: (Toggle Plain Text) GLfloat* mBar GLfloat* mBar Well, actually I was most curious about if it was possible in some way to forward declare data types that are typedefed. The reason is that I want my header file free from dependencies. The GL include file might have been a bad example though...

May 21st, 2006, 1:30 PM	#4
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	Generally speaking, the compiler needs to know enough to emit code that will implement your statement. It may emit that code with temporary entities which will be filled in by the linker (or even at runtime), but those temporary entities must be of the correct form. If you declare a pointer, as in GLfloat* mBar, the compiler knows what size of entity to allow for, because a pointer is a pointer is a pointer (generically speaking, please no one jump on near/far/et.al pointers). At some later time, the compiler is going to need to know what TYPE of pointer that is, just to make sure you didn't goof up in your subsequent usage. This is really more a favor to you than anything else. If you declare a GLfloat, though, the compiler is going to need to have some pattern for that to go by. It could be a twelvety-four byte structure, or something. You get my drift. Include files "go away" before the compiler even comes onto the scene. By that, I mean that the preprocessor essentially copies and pastes the contents of the include file into the source and THEN gives the compiler the whole shebang. If the compiler didn't need that information, there would be no need to include the file. If it does need the information, and it's not available, there's trouble in River City. The preprocessor also expands macros and so forth. Your cute little #defines are not seen by the compiler; the result of expanding them is seen by the compiler. The '#' indicates entities to be dinked with by the preprocessor; they're gone, only their effects remain, in the material the compiler works with. One should have a mental perception of the (at least) three separate operations that take place in going from source code to an executable file: preprocessing, compiling, and linking. There may be a locating step. That may be handled by the system's executive. It varies from system to system and operating system to operating system (if there even IS an operating system worthy of the name). __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

May 21st, 2006, 1:59 PM	#5
Klarre Game engine designer Join Date: May 2005 Location: Sweden Posts: 309 Rep Power: 4	Thanks alot for your response, and time! That was what I wanted to know. /Klarre

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Programming Forums > Application Development > C++

Forward declaration...