Skip to main content
gamedev.net
🔒 Locked

Good Practice?

Started by Jason2Jason Jun 1, 2003 at 5:44 PM 9 replies 900+ views
Original Post
Jason2Jason
Jason2Jason
Hi. This is a question of good programming practice. I've just been working on a solution to a problem for a while and it seems to work. The problem was that my image class was being called to try to use the image libary i use before the critical initialisation funstions were called. You may ask why not just wait untill these were called. The answer was becuase it's rooted in the constructor to a class that is defined in the main game class. So basicly it was trying to use a system that wasn't initialised yet (like trying to drive a car without any petrol). I did this fix in the constructor: 
CDevILImage::CDevILImage()
{
#ifndef DEVIL_DEFINED_
#define DEVIL_DEFINED_

	ilInit();	//Initiate DevIL libary

	iluInit();	//Initiate DevIL Utility liabary.

	
#endif
}
This looks simple, and believe me i was hitting my self woundering why it took me so long. Any way, is placing preprocessor commands in normal function bodies good coding practise? It works but it might not be up to standard. Should i go with just making a global or static var using normal if statements making its a little more complicated (when dealing with more includes)? I might just be too worried about this.. Thanks, -J [edited by - jason2jason on June 1, 2003 6:46:21 PM]
Jan Wassenberg
Jan Wassenberg
I assume your problem is your constructors for global objects getting called before main (in whatever order).
I don''t see how the #ifdef could help.

BTW, this problem is an argument against putting code ''services'' / modules in a class (which isn''t inherited from / instantiated more than once). I like well defined init / shutdown order...
*dons asbestos suit*
E8 17 00 42 CE DC D2 DC E4 EA C4 40 CA DA C2 D8 CC 40 CA D0 E8 40E0 CA CA 96 5B B0 16 50 D7 D4 02 B2 02 86 E2 CD 21 58 48 79 F2 C3
Jason2Jason
Jason2Jason
quote:
Original post by Jan Wassenberg
I don''t see how the #ifdef could help.


Its actully #ifndef, note the ''n''. Its just like an inclusion gaurd.

I''m unfimilure with this debate, perhaps you could enlighten me?

I had a class that contained this image class, so the constructor of that was called before to init code got a chance to be called, so the roblem arised.

Actully thinking about it perhaps i should use a static member and a if statement.

Hmmmm..

-J
fizban75
fizban75
So, your problem is order of initialization?

My suggestion would be to store pointers to the objects and create them in the order you need them with new, then delete them in the correct order in the destructor. Simple and easy.

The other solutions are to move the DevIL initialization to another place that is guaranteed to be created first, either a global variable or a singleton (where it will be created the first time it is needed), or in a class higher up in the inheritance chain, since the parent class will be created before the child class.

For instance, you could have a base class called "app" that contains the DevIL object, then derive your class from app and have it contain the image object. Then, when you instantiate your derived class, you can be guaranteed that the DevIL object will be initialized first and ready for use by the image class.


[edited by - fizban75 on June 1, 2003 9:43:29 PM]
C-Junkie
C-Junkie
You''re confused.

Preprocessor directives are evaluated at compile time.

your code will NEVER call ilInit or iluInit that way.
Aface
Aface
AP : i believe "ifn" is only a redneck term if used in the following code block

#ifndef CLASS_H
#yalldefine CLASS_H

aface
Qw3r7yU10p!
Qw3r7yU10p!
The preprocessor is a simple text replacement. That code deosn''t do what you think it does.
Jason2Jason
Jason2Jason
OK thanks, thats cleared that up. It seemed to work, but doesn''t as you guys said. I didn''t think of making it a pointer then alocating it after main init was done. Thats what i get for coding late at night

Thanks again,

-J

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.