CleanCode Quake II has gone public!

[Paril]

The key to portability is to avoid compiler extensions and OS-dependent functions or classes that don't have equivalents. Nothing is more annoying than dealing with a bunch of code full of #if WIN32 directives. Your OS dependencies should be wrapped such that your code hides these details.

Hence cc_platform.h.
Microsoft extensions (the ones that MSBuild put under "non-standard") are all disabled and a warning is brought up if any such as issued. Of course there might be other "little" extensions that don't raise this error, such as using a templated class as a base but not using the template arguments inside the class itself:

Code: [Select]

template <class what>
class CWhatever
{
};

class CTwo : public CWhatever<int>
{
    CTwo () :
      CWhatever ()
      {
      }
};

Whether the standard allows for this I don't know; VS6 didn't like it one bit. A VS6 project is still in development, but there are a lot of required changes before it will function.

As for #if WIN32 and such, I haven't been able to remove all of them as location matters in this case, but most of them are in Platform.h and cc_platform.h.
It can be confusing to programmers to have to manage all of these little details, but nearly every "cross-platform" library or application is swimming in these statements, and sadly there's not too much people can do about it other than wrapping the crap out of every function that is OS-dependent (which also becomes useless if, for example, one platform doesn't have the same functions another platform does)
Example being Sleep(0), which every Win32 programmer knows the meaning of but might have no use on any other system (besides them maybe not even having a proper sleep function)

Also, DON'T use constructs in your code like __CC_DEPENDENCY_H__ with leading/trailing underscores. Functions, variables and constants with leading underscores are reserved to the implementation, (the compiler writers) not user namespace. Functions with leading underscores for example, are compiler extensions or non-standard C runtime functions that are platform/implementation dependent and you should not use this namespace for your application code. If you find yourself using leading underscores or double leading underscores this is supposed to be a clue that you are venturing into non-portable territory.

Reason I used leading/trailing underscores is to avoid name conflictions with anything. I am aware that they are reserved, and it just developed into using that without much thought. I'll remove any trailing/leading underscores that I can find and hopefully won't break anything in the process.

There should be almost nothing in a Q2 mod that is OS dependent. The only exception is the code necessary to support the different DLL implementation and names. (Although I confess to using OutputDebugString occasionally, I undefine it in the header on non-windows platforms.) All the OS dependent code is in the engine, the mod only needs to call the engine API. All other functions in the mod should be completely contained and defined in the mod code, dependency on outside packages makes modding harder, not easier. If he downloads the wrong version of the package the modder ends up debugging the package, not his code. If you import package code then ship that code with the project. Make no use of Windows API or classes.

There shouldn't, but sadly I had to use some complex hacks to get a class-based Quake 2 to work properly. A good example is the fact that I had to have a DLL initialization function (DLLInit/DLLMain) to initialize CleanCode's own memory system. Linux that I know of supports a function that will be called before the CRT initialization and should have no problem with this, but there was no other capable workaround as static STL containers used our own memory allocation.

You should consider creating a VM and running your code through the GCC compiler concurrently with your Windows development since the vast majority of active servers are on Linux. idSoftware made the mistake of not paying enough attention to this and they ended up massaging the entire Quake 2 code base for Linux and the 3.21 release. OO helps you in this case since you can conceal platform dependencies inside a class but again, this should not be necessary at the mod level.

VM is not an option at this point, to keep complexity to a minimum. Porting to Linux should be straightforward, the problem I see is DLL initialization and possible compiler conflicts not liking VS08+ constructs and features (Microsoft extensions)

ALWAYS test your conditional switches and pathways to be sure they work. Test all cases to be sure your project builds successfully under all conditions of switches and packaging. Obviously, the more switches and special configurations you have the harder it becomes to maintain.

This has been a goal all the way through, problems arose mostly when I was working on systems like monsters and pathfinding or something would be left out, the codebase is constantly updated with fixes and it just happens that sometimes a fix breaks another fix. That's why we have SVN, and we're working diligently to make sure that these conflicts don't happen.

-P