Ok, in writing my engine I''ve ran into sort of a roadblock. I''m writing my engine to not only be API independant (graphics, audio, input) but also follow ANSI compliancy as close as possible, hence it would also be OS independant. However, I''ve ran into a problem which I can get around, however I''m not sure which approach is the best to take. Here''s my problem: I''m creating a Directory class that lists all files in a given directory. This will be used to automatically load external library files (.dll, .so). However, you can''t use the same functions to get file listings in Windows as you do in Linux, bringing me to my problem: how should I implement os independancy in certain files? Here''s a few solutions I can think of, but none of them sound like a "best approach": 1.) Create a Directory virtual base class, and derive WinDirectory or LinuxDirectory from that. Upsides: It clean, and very portable since all OS specific code are kept seperate. Downsides: It''s a tad slower (virtual functions). It requires an #ifdef every time I want to use that class in the code of my game. 2.) Do the above and use a Factory pattern to get my Directory class. Basically, I would have one class dedicated to returning all OS specific classes, called OSAbstraction. Upsides: Same as above, but it would also keep all #ifdefs in the same file (the OSAbstraction file). Downsides: It has another level of indirection for creating classes, causing a slight speed loss. Uses virtual function, causing another speed loss. User has to remember what low level classes are OS specific and which aren''t (in other words, which they can use directly, and which requires going through OSAbstraction). The factory pattern is more useful when the type returned is NOT known at compile time, not the other way around. 3.) Create one Directory class that has #ifdef WIN32 sprinkled all throughout the class for the few OS specific functions. Downsides: It is harder to maintain and support. Adding support for another OS requires small changes to many files. Upsides: No loss in speed. Don''t have to use #ifdef''s directly in my game code. I''m more apt to go with option #2, but I''m still not certain it''s the best approach. What do you guys think? - Houdini

Hmmm, you''ve completely lost me there.
What''s wrong with writing a set of wrapper classes (or using existing ones), compile these for the different OS/API''s you want into library files, then link your program to whichever library OS/API you want to target?

ifdef? thats where macros come in, good old:

#ifdef
#define DIRECTORY LinuxDirectory
#else
#define DIRECTORY WinDirectory
#endif

only once should ifdef be used

-----------------------------

A wise man once said "A person with half a clue is more dangerous than a person with or without one."

The Micro$haft BSOD T-Shirt

Or better yet (IMHO) use typedef instead of #define. You can also put the Linux and Win32 stuff in different namespaces and put the appropriate "using Linux" or "using Win32" in your #ifdef.

As ImmaGNUman says you should only need one #ifdef in a header somewhere.

As for using virtual functions, come on, if you''re touching the disk you could make a thousand virtual function calls and barely get out of the noise as far as the performance hit goes. People obsess about negligable factors like this *WAY* to much...

-Mike

I would agree. You are not going to have one executable that runs on multiple platforms. I supposed technically you might be able to do it as long as it was the same processor family and register conventions, but that would make it needlessly complicated. So realistically you are not going to determine what platform you are on at run time and any effort to do so is just wasted. You can''t compile a call to a OS specific function when you compile on a differant platform than the one it is specific to. So there isn''t a need for LinuxDirectory and WindowsDirectory. Just name it Directory. When you build the project on Linux you include the function specific to Linux and when you build for Windows you include the function specific to Windows. If you have them both use the same header file then it is completely controlled by the make.

Have like a Directory.h, LinuxDirectory.h and WindowsDirectory.h. The platform independant code includes just Directory.h. The Linux specific code includes both LinuxDirectory.h and Directory.h. The Directory.h guarantees that the functions used by the platform independant code has the exact same definitions on both platforms. Includes specific to the platform or internal functions for the platform specific code goes into the LinuxDirectory.h and WindowsDirectory.h. In one make file LinuxDirectory.cpp is part of the build while in the other WindowsDirectory.cpp is part of the build. There is no reason for WindowDirectory to know there is a LinuxDirectory.