The Stack Frame

Just letting any readers know that very soon I will be updating the site in a radical way. Large changes are to be coming.

2. Improved Preprocessor

Obvious but true — the CPP (C Preprocessor) is absolutely horrendous. It works for very basic things, but it does NOT blend well with templates, and templates are rather limited in strength.

We obviously cannot remove the CPP alltogether as that would destroy any backwards compatibility of older code that uses macros and such.

What I propose is a new, stronger preprocessor system, that has access to templates as well.

This preprocessor should be able to see compile-time types, write and read files, etc. I should be able to write an entire preparser/metaparser in this language and have it be valid C++.

In addition, I want the ability to define new modifiers. For instance, I want this to be valid:

modifier _script ()
{
printf("%i", __line); //prints the line where the modifier is used
printf("%s", __file); //prints the file name
printf("%s", __expr); //prints the entire expression in which the expression is used
__write("temp.txt", "The script modifier was used!");
}
_script int echo (const std::string &in) { printf("%s", in.c_str()); }


Basically, by using a variant of C++ as the preprocessor, we gain immense flexibility and power.

More to come later.

Sorry for the lack of posts in the last few months — I’ve been trying two things:

Although seemingly incompatible, both are means to the other’s end. Back in January, I started an Indie Game Studio, Vindictive Studios, with my friend and former codeveloper from the Galaxies Emulator Eric Dyoniziak. Things fell through, him with school and all, requiring rapid development versus my preferred slower pace of development. As is, I am still deciding whether or not I wish to retain the Vindictive name.

Either way, I am continuing development on our interface library as part of my engine, which is currently in development. Here are a few of the proposed features:

I will post a more exhaustive list and more information once the engine becomes more mature. It is still very, very much in it’s infancy, and couldn’t write a fly-simulator let alone a game.

Either way, during it’s development, I realized there are some things that are lacking in C++ that I would oh so very much enjoy…

1. Static Template Conditionals
I want to be able to explicitly create a static template conditional, meaning I can make a conditional that is only used compile-time that can use template arguments. As an example:


template <typename return_type>
return_type callScriptFunction (const char *func_name, const char *param_types, ...)
{
...
return *(return_type*)getVarPointer();
}


You can see the problem with this. If this is a void function I am calling, and I feed the template ‘void‘, I am dereferencing a void *, and creating a ‘void‘ object, both of which are illegal.

But what if I could do this:


if <return_type != void>
return *(return_type*)getVarPointer();


The compiler can tell it is static and will compile without error.

I don’t think I will ever be able to do this in C++. Maybe in D.

I will be adding more to my wishlist later, until then, adieu.

As I’m sure many of you know, I was a lead developer on the Star Wars Galaxies Emulator for about six months back in 2006. During that time, I basically headed dynamic server research and development.
Why dynamic server? At that time, we were very uncertain about how to properly structure a server to interact with the client, and very uncertain about packets – we therefore had two servers: the static test server and the dynamic test server. The static test server was regularly maintained by the heads – Ramsey, Ultyma, and Xenozephyr. It was a single-user server meant to test packets. That was it’s purpose. Packets were broken down, tested on the static, then released to be implemented in the dynamic server.

At the time, the current dynamic server was known as Core1 – it was inherently a broken down version of the World of Warcraft Emulator server. This was NOT a good design for the SWGEMU – WoW is an inherently different system, not the most of all that it uses TCP/IP for its packets, not UDP.

As I was on the team, we continued to refine Core1, and after our lead dynamic coder left, I was left with the mess that was Core1 – a junk of a server that was completely unstable. After debugging and rewriting it twice to make it suitable for public testing, I came to the realization after reading over packets that it was NOT structured properly for this task — I therefore set out to write a second dynamic core, known as Core2.

The team leads, however, wanted to push forward, and in their minds this meant working on a release server, as they felt that enough research had been done that we were at that stage. I disagreed; not long after, I was no longer on the team. I continued work on Core2, and although it does not have many features, it is today the most stable SWGEMU Core there is.

The Emulator team, however, pushed forward with Core3 — they added CORBA support for clustering, the remainder of packets, all written in C. Not C++, C. Not recently, they had to do a complete rewrite of the engine to support Object Orientation, not least of all because they did not finish basic research. The purpose of the Core-series of servers was not to make a release out of it, but to study the proper design. I entirely anticipated being at Core5 before we were ready to make a true release – the team rushed, and even now the server is rather unstable.

Research and Development is important in server design – different servers require different designs, and the most optimal design is the one that after several tests proves to be the most efficient and the most stable – for a server that is meant to support maybe 2000 players, is a clustering-compatible server with extension support really the best means? Why is it the first choice and the one went with? R&D would have filtered out such a design before it became the basis of it.

‘virtual‘ — for some reason, one of the most hated modifiers in the C++ Programming Language? Why, I ask? Is it the perceived great loss of performance? Is it that people don’t understand how it works? Lacking specific benchmarks (which I will have in an upcoming article), virtual methods do indeed incur a cost penalty during runtime… whether or not these penalties are signifigant depends more on the structure of your application than on the manner in which abstraction in C++ functions.

There are two basic ways in which one can handle abstraction in C++: the first, and unfortunately still one of the most common, is to take a C-approach to the problem – inside every ‘abstract’ method, you simply do a conditional test, and then execute the relevant method. This is indeed the most efficient manner by which to execute an abstract method call, runtime-wise. It does, however, look terrible:

/* C-style Abstraction within C++ */

void foo () {

if (isGL)

GL::foo();

else

DX::foo();

/* or */

bool(isGL) ? GL:foo() : DX::foo();

}

The manner by which C++ prefers you to handle this is by using the virtual modifier. The virtual modifier flags your object class to be an abstract class, with it initializing a virtual table (vtable) which carries pointers to all the possible end solutions – as you can imagine abstraction by means of virtual can become quite slow if a class has many parents before reaching it’s base abstract class, and that’s without taking into account the possibility of multiple inheritance!

/* C++-style Abstraction within C++ */

class Base…

virtual void foo () = 0;

class GL : public Base…

virtual void foo () {…}

In a modern system, the only time I can understand someone not using C++ virtual methods are when the objects that are abstracted are going to be used constantly, perhaps during 30% or more of the applications run time – that’s the situation in which the performance overhead from using virtual methods becomes signifigant. Assuming you are using Microsoft Visual C++, you can use the class attribute __declspec(novtable). What this attribute tells the compiler is that the current class is purely abstract, and does not need to initialize the virtual table pointer for itself in its constructor, as no method within it will ever be called. I find the benefit of this to be unclear performance-wise at best, and it is not supported outside of Visual C++ – I also suspect that the compiler is fully capable of detecting whether or not a class is purely abstract, and to take the proper course in optimizing it.

Please, though, I am very tired of seeing spaghetti code and functions made up of conditionals that don’t belong – please don’t be afraid of C++-style abstraction! It’s your friend!

Garbage Collection has become a mainstay of many programming languages… Java, C#, LUA… but why? The answer is simple: people are lazy, and want to do things quickly… but what is the cost?

I had worked on the Star Wars Galaxies Emulator as a developer for several months, and there was a Junior Developer on the team who was originally  Java programmer… and his C++ skills were atrocious: allocated objects that were never released, floating pointers that went nowhere… the server dæmon crashed more often than not because of mismatched pointers, and the memory leaks were terrible. He ended up leaving the team due to conflict over this. Garbage collection, and particularly getting used to garbage collection, has the overall tendency of destroying one’s ability to program: even if the language allows or even requires you to not release objects, not doing so detaches you from the structure of the program – you are no longer following your objects in your own map of the code in your mind.

Now, nay-sayers will say that it is too complicated to manage objects in C++… particularly in that both the C-style allocator/release functions malloc and free are present, and the C++-style allocator/release operators new and delete are present, and are not mutually interchangable… although I generally consider it bad practice within a single module to interchange the two, I find it completely acceptable to interchange them within the same project, especially if you are using a naming convention that assists you in knowing which objects were dynamically allocated using malloc, and which using free – by interchange divided by module, I am referring to if I make a class that does the same thing std::string does, I find it perfectly acceptable to use malloc, realloc, and free in order to handle memory allocation for the resizing array, as those functions are not being exposed to external modules; in fact, I would go as far as to say that it is irresponsible to use the C++ allocation operators in something as simple as that given that there is never going to be a defined constructor for a char type.

From the perspective of performance, handling your own memory management is the only way to guarantee a set level of performance within your application. Garbage collection requires the application to periodically check the object’s allocation references, and test how many references to it are active. On some systems such as the XBox 360, this can be devastating, as there is an error in their code which causes their collector to check every single object during every single allocation, which can become quite slow. There are other systems as well, but just remember that this is accrued overhead, and overhead on some systems can become tragically inefficient, particularly when your application requires you to have higher speed -and- the flexibility of being able to allocate many objects over its lifetime (i.e. projectiles in a game). In the very least, I would like it if more of the garbage collected languages would allow you to release objects manually; C#/XNA, for instance, requires you to use their flawed garbage collector – I suspect that this may be purposeful, however.

If you would like to have some fun with memory management and data structures relating to memory management, I lightly suggest that you attempt to make your own standards-compliant versions of the base STL container classes such as vector, list, and map, and see if you can make them better performing than what your system uses by default.

Java and C++ are both very well known and very popular programming languages. I have, however, been most irritated lately by the multitude of people claiming anywhere from Java being a better organized language to Java being more powerful/faster/so forth. I hope to at least add my commentary on the debate.

Java is most definitely a useful language; it possesses its own niche in the world, similar to the niche that SCUMM held in regards to game development in years gone by. SCUMM and Java both allow the developer to write in a generally simplified, interpreted language, by which one need only rewrite the interpreter for each system, not the entire application. The befalling problem is that it is generally far slower to interpret bytecode than to execute native machine operations. This problem, however, has been solved in recent years by a simple technique known as JIT – Just-In-Time [Compilation]: instead of interpreting bytecode, we compile the bytecode into assembly before and sometimes during runtime — this technically allows for a JIT’d language to potentially be faster than natively compiled executables in that optimizations may be added during runtime, versus requiring all optimizations to be made compile-time as with native languages such as C++.

Java has been losing quite a bit of ground lately, due to a variety of factors… I believe the most signifigant appear to be the rise of competing languages, such as Microsoft’s C#, and the fact that many applications are being developer for the XBox 360, requiring users without expensive Development Kits to write with C# and XNA… this has also caused C++ to lose programmers.

My primary argument against Java, though, is garbage collection — one of the best tenets of a programmer is his capability to visualize to himself the structure of a program and to manage it’s function; if he cannot remember to delete an object, then perhaps what he is writing is too complicated for him. I do apologize, however, as this is a bias on my part as a C++ programmer — I cannot stand the sight of a lack of a delete operation after a corresponding new. Garbage collection also adds an inherent overhead onto the application, which can often be somewhat significant (see the XBox 360′s XNA interpreter).

C++, although many Java programmers will tell you otherwise, is not an out-dated language. It still serves, and continues to serve, a very important function in programming. It is true, computers are beginning to become fast enough where interpreted and runtime-assembled binaries are becoming fast enough that they can compare to natively-assembled binaries — however, C++ is the language in which the vast majority of their interpreters and assemblers are written in. C++, in general, also allows for the greatest speed — the times where Java and other interpreted languages are faster are exceedingly rare and for the most common of tasks, C++ is amazingly faster… to write proper and effective C++, however, it generally does take one longer than to write a similar albeit less efficient program in Java or some other higher-level language.

I heavily encourage new programmers to learn C++. It is a very useful language, and if you can successfully write C++ code that both functions and is clean, then it is not a long step to learn another language such as Java, Python, or C#… the majority of other major languages are at least syntax-similar to C++, and they function in much the same way. Knowing C++ very well will also make you a better programmer in particular as you will understand better how the system works, although learning Assembly will also help with this, and how to better optimize and structure your code. As for Java programmers, if you do not already know C++, perhaps you should learn it. C++ is extremely similar to Java – Java’s syntax is based upon that of C++. It never hurts to broaden your horizons, and knowing a lower-level language as compared to Java never hurts… it can only help you write better code.