Porting Back to Linux II.

This post is the second part of another I posted earlier.

The detection of uninitialized class members is one of  of my recurring problems with C++. The language standard does not guarantee anything about member variables so I should initialize them myself. Unfortunately, VC++ compiler does not warn me if I forget to initialize a class member variable, even if I set the highest warning level. GCC detects this kind of sloppiness and reports them to me keenly, making great improvements in code quality. Furthermore, GCC goes one step beyond and warns me if the initialization order differs from the declaration order (see Effective C++ about this).

I observed similar  behavior on hidden virtual methods. If I accidentally define a function in a descendant class with identical signature to a virtual function in one of its base classes then VC++ compiler does not give any warning about this.

There are further useful warnings in GCC. If I do not declare copy constructor or assignment operator for a class but try to involve this class in value assignment or pass it as a parameter passing by value, then GCC warns me about my mistake. This is very useful on classes those have dynamic data, avoiding memory leaks and double delete operations.

Missing virtual destructors are also detected by GCC: if a base class has virtual destructor then it is highly recommended to make the destructor virtual in its descendant too, if the base class manages its own dynamic resources by itself in its destructor.

Unused function parameters are handled by the two compilers differently. In VC++ we can use pragmas (#pragma unused) or casting to void type to suppress compiler warnings complaining about them. In the GCC world, it is enough if we do not give name to the parameter and the compiler will not nag us.

So far, I found GCC is much better in handling of typical C++ programming mistakes done by me. But there one thing that I found quite unlovely. GCC does not allow to use >> token in template declarations. For example:

Collections::Array<GraphNode<W>> _nodes;  // token '>>' is&nbsp;recognized&nbsp;as
                                          // a shift operator by GCC, so the whole
                                          // declaration is syntactically seems
                                          // to be incorrect for the compiler
Collections::Array<GraphNode<W> > _nodes; // it is all right

Up to this point, I have dealt with compilation issues only. After I have cleaned them, I had got the whole program compiled with no problems. It was the time for fixing run-time bugs… 🙂

First, there were some platform-dependent codes, like time and date handling, platform-specific string formatting and other safe string and I/O operations. I have had to rewrite the text I/O for the game console. I have had to remove all references to the PhysX library from the source tree, because there is no Linux support for it. I began to think about replacing it with another physics engine like Bullet.

I have had some problems with the OpenGL version I have on my Linux. It is a quite old, and as it turned out does not support all the required features I need to fully operate the engine. GLSL is older too and complained about some minor syntactical issues like ‘0’ is an integer constant and it can not be converted to float… :-/

Finally I have got the engine running on Linux, but it has some missing features due to the lack of some OpenGL functionality, and there are some rendering bugs too. I will not keep on working on the porting task until I have a new and appropriate hardware.

After all, I consider the porting attempt as a success. I have fixed countless programming and aesthetic issues in the engine. The code became much more clean and consequent, compiles without problems on Linux. Although it is not able to run flawlessly but I think it is not wort the effort to chase bugs further in an inappropriate environment. But this topic will be continued as soon as I have got a new hardware. I hope it will be soon… 🙂


Posted on November 24, 2011, in C++, game engine, opengl, porting and tagged , , , , , , , . Bookmark the permalink. 2 Comments.

  1. Regarding the >> thingy – just use C++11 (or C++0x) 😉
    You supply GCC with -std=gnu++0x (don’t know which version of GCC started to support this, but I am using 4.6.1). BTW, GCC 4.7 will be much more C++11 compliant (lots of features I am waiting for).

    But, seriously, C++11 also allows a lot of other cool features besides a little easier typing (thinking >> and the new null_ptr and auto keyword).

    • Hi Nicolai,

      first of all, thanks for your comment. Yes, you are right, these are very useful features indeed, and it would be good to use them in the engine. But I am cautious about these features, they are relatively new, and not all of them are supported in these compilers. Moreover, the compilers support different subset of these features, so if a feature is available in GCC is not neccessarily means that it is available in VC++, and vice versa. The source is quite large, and there are parts those are very old and deprecated and require some rewriting, and I think it is more important than to quickly switch to the new features everywhere. This kind of global feature replacement requires a lot of work and may have some pitfalls that would consume lot of time, and would be boring too 🙂 Of course, the future is that to use as many as possible to make life easier.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: