The engine won't be opensource, at least not at this point. If i decide to stop working on it (like i did with IUE - the UE version available at the site) i might release it though, but at this point i don't care what others will do with it
.
I find C++ slow (for compilation - for executable speed the difference is very minimal and in some cases i find the code generated by g++ to be slightly faster than the C code generated by gcc) because it takes a lot of time to process a "proper C++" source code file (with proper i might files that use C++ features such as classes, templates, namespaces, etc). I've used and wrote a lot of engines and libraries too and i still have this impression.
When i'm talking about simplicity i'm also including the ability to have everything in one's head (mine actually) and being able to follow the program's flow easily. For example this code:
foo = bar[3];
is straight dead simple what will do in C. But in C++ it is not. The assignment operator for foo might be overloaded. Or the index operator for bar. Or both. To be sure you have to know what foo's and bar's classes are and what operators they have overloaded (and looking at the class declaration code isn't enough - you have to be sure that there isn't any toplevel operator declared either). This isn't something hard to do of course, but it adds extra micromanagement overhead when you are debugging and simple things such as this is the source of most bugs. Not to mention that this sort of things add up quickly - you're not going to use the overloaded operator in a single place or else you wouldn't overload it at all.
Do not focus on this example, btw. It is just that: an example. There are other issues i have with C++, including style issues (f.e. i hate the
foo_cast syntax - it looks plain ugly and i can't really say that i like the Class::Field syntax too).
Keep in mind that getters and setters have nothing to do with classes. There isn't much difference between
e->getHealth()
and
ent_get_health(e)
Of course you type a little more code in the second case, but it has been more than a decade that i've got past the mark where typing a few extra characters makes any difference in the time i need to finish something
. Besides i wouldn't use "get_health", but simply "health" since i prefer to avoid using the "get" and "set" words unless the function's purpose is not clear.
Although at this point one might ask: why you need a getter and not use e->health directly? This is the "rethink" part that i like to do that keeps things simple. In this case i would use e->health directly and make sure that it gets the right values.
Note, btw, that C isn't immune to all C++ issues. In practice you can do in C whatever you can do in C++, but its a little harder and in the process you know you're abusing the language and, at least in my case, you come to think if this is the right way to do it. But C has its issues too - which exist in C++ btw. An example is the abuse of macros, which is a reason i try to avoid them unless they're very simple.
Someone else using the engine will have a problem understanding the engine in any case - being written in C++ or C wont help much. This is why documentation exists. But i believe there will be more issues with understanding an engine using C++ than a C engine because of the language's simplicity. At least that is the case with me.
Author
