Archive for the ‘C++’ Category

Watch out for empty constructors

Tuesday, December 18th, 2012

Well, this is a pretty rare caveat, but took me some time find. And it is a very subtle case of wrong assuming of things.

I will show this with an Ogre example, but the principle is the same in many other similar situations.

Ogre is a 3D engine, and naturally, has some convenience math classes like Vector2 or Vector3. Each such class has a number of constructors, both in form of ::Vector3(float x, float y, float z), but also in form of just a ::Vector3().

And at least for me, it is very easy to assume that a ::Vector3() constructor actually initializes the object to some default state, which for a vector would logically be (0,0,0). But when you think about it, it is not so certain at all… Also in my situation in release builds, these objects would be initialized to 0s anyway, even though I am sure it’s is technically a case of Undefined Behavior. In debug builds, this was not the case, and naturally, it created some nice bugs.

The moral of the story, be aware that empty constructors of such small data classes do not necessarily initialize any state of an object, especially when such classes have static members like Vector3::ZERO, which suggest that this is the default and best way to create a zero vector (like they do in Ogre).

Implementing win32-events with Boost

Thursday, November 29th, 2012

I’ve been trying to modify the Hydrax sources for a while. Hydrax is a great project that renders quite pretty water, but has some performance problems, the main of which being the fact that it renders the heightmap of the water using Perlin noise on the CPU, and does so synchronously. Ogre, which is the 3D-engine that Hydrax runs on, is already pretty single-threaded, which works out relatively well, but not when Hydrax adds the noise generation to the already bloated singlethreaded CPU-part of the Ogre render cycle.

So the basic idea was to take the heightmap-generation and put into another thread which will execute on another core while the main thread does the rest, including waiting for the GPU to render things. (Yep, that’s just how single-threaded a stock Ogre application is.)

Hydrax stores the height-map in a handy blob of vertex positions (also colloquially known as the vertex buffer), which is then just fed into the mesh class in it’s entirety every frame. This gave me a nice practical possibility to just have a secondary vertex buffer which would be updated in the background, so that the primary one will be free for usage by the mesh in the main thread (I didn’t have any control over how it’s used, nor wanted to dig into the details of that), and then the only place I would need to synchronize the threads would be the point of switching the primary vertex buffer to the secondary buffer which has been generated/updated in the background.

Hardcore debugging crashes in C++ release builds in Visual Studio and StackWalker

Monday, May 30th, 2011

Ever encountered an error which just shows up in a release build? And when you are debugging everything is just fine? Don’t those errors just make you happy and loving the programming, computers, the world and everything in it? 😛

So, long story short, I had to come up with some reliable debugging methods for the release builds, and there are quite a few.

tolua++ windows precompiled binary exe file download and more instructions on tolua++.

Sunday, October 17th, 2010

So, since the last post, I have started embedding lua and has had some minor problems.

First I tried using luabind, which didn’t work at all for me. I didn’t want to include and build both luabind and boost (which it requires), and all of the precompiled solutions didn’t work either on my setup for different reasons, plus I just didn’t have time nor motivation to spend an hour trying to setup paths, projects, solutions, includes and so on for a library which should be precompiled.

So I thought screw luabind and I will go with tolua++. Which does almost the same thing but in a different way. Basically, luabind is like a library with a lot of macros, which you use to define your bindings in certain way in your code, and when the macros get expanded before compilation, the bindings start working. Tolua++ (and its predecessor tolua) on the other hand, only includes a very small runtime library, and most of the work is done before compilation by an external command line tool. It takes in special header files which you must write for your bindings and converts them to cpp files which you then include into your project like any other cpp file, and all the bindings are defined there. (This step is automated of course, you only define the special header and include the output file once).

tolua++ doesn’t require boost, which would mean less trouble compiling it, and also I thought that the exe file itself would be just downloadable precompiled.

However it wasn’t. But now after some time figuring out the compilation routine, I have compiled it and thought that I can put it out here for everyone who wants to save an hour or so by just fetching the file which should have been available from the author’s site from the beginning.

Anyways, here is the binary. It is for win32 and is tolua++ 1.0.93:

tolua++ 1.0.93 compiled binary (exe).

When compiling this, I have had a great help from this guide:

Although some things in that guide seemed to be incorrect, so here is my modified version: Tolua++ compilation guide.

As for actually using the tolua++, here is another awesome guide which should get you started:

Compiling Tolua++ 1.0.93 without SCons (updated)

Sunday, October 17th, 2010

This guide is based on the
I just have modified some things in the Visual Studio part, because in the original, the steps didn’t work for me.

So, needless to say, most credit goes for the author of the original guide, I have just modified some stuff!

I wanted to post this on the tolua++ site but they dont have a wiki.

The tolua++ INSTALL file lets you figure out how to compile it without SCons. Its easy enough, but I wanted to save the people the 5 ( err… 15 ) minutes they need to figure this out.

Using GCC/Mingw

I am using gcc 3.4.2, on a mingw installation. But I think this should work for most people, at least those using gcc, with minor modifications.

The commands used are :
tolua++_1.0.5\src\lib> gcc -shared -o tolua++.dll *.c
\Lua502.dll -I..\..\include -I
– This will create the dynamic library tolua++.dll in the src\lib directory.
tolua++_1.0.5-1\src\lib> gcc -c *.c -I..\..\include -I
tolua++_1.0.5-1\src\lib> ar rcsv libtolua++.a *.o
– This will create the static linking library in the src\lib dir.
tolua++_1.0.5\src\bin> gcc tolua.c toluabind.c -I..\..\include -I
\Lua502.dll -L..\lib\ -ltolua++
– This creates the tolua++ executable in the src\bin dir, assuming the libtolua++.a was created in the src\lib dir.

Note1: If you are linking against the lua static library instead of the dynamic library, replace
\Lua502.dll with -L
\lib -llua .

Using Visual Studio 2003

Library (.DLL/.lib)

Open the “File->New Project” menu. From the project types listbox, select “Visual C++ Projects->Win32”. From the Templates listbox, select “Win32 project”. For a project name, type in “tolua++”.

When the wizard opens, select “Application Settings” on the right hand side. Choose “DLL” and click ‘Finish’. If you want to compile to a static library, choose Static Library (.lib)

In the Solution Explorer right click on “source files” and select “Add->Existing Item”. Browse to the location of the tolua++\src\lib directory. Highlight all .c and .h files and add them to the project. You may also optionally want to add the tolua++.h file from the include directory into the “header files” folder.

Right click on the tolua++ project in the Solution Explorer and select “Properties”.

Under the “C/C++ -> General” section select the “Additional include directories” option. Navigate to the location of your Lua include files.

Under the “C/C++ -> Preprocessor” section add the following: TOLUA_API=extern __declspec(dllexport) Under the “C/C++ -> Precompiled headers” section, turn off precompiled headers. Under the “Linker -> General” section select the “additional library directories” option and navigate to the location of your Lua .lib library files. Under the “Linker -> Input” section add lua.lib and lualib.lib (assuming those are your lua libraries).
In more recent versions of lua there is just one library, for example “lua5.1.lib”. In that case, just include that.

Compiling the project should result in a tolua++.dll. or tolua++.lib, whichever you chose in the project settings.

Executable (.exe)

Now, to build the executable, you must first build the library. And even thou there is probably some way to do this using the .dll for of the library, it’s easier to do it with a static one. So before compiling the executable, first compile the library as a static library (not as .dll (project settings)), to get a proper .lib file.

To create tolua++.exe, open the “File->New Project” menu, select Visual C++-> Win32 -> Win32 console project. Add the files “tolua.c”, “toluabind.c” and “toluabind.h” to the project. (NOT toluabind_default.*)

Similarly to the previous step, add the lua .lib include directory (in project settings – linker – additional library directories) and the lib itself (project settings – linker – input (just write the library filename there (no path)))

If you have listened to my advice and linked the tolua++ library statically, don’t add anything in the “C/C++ -> Preprocessor” section. If you went with dll, you will probably have to add
“TOLUA_API=extern __declspec(dllimport)”

(NOTE: this is not the same line as in previous step. That one was with dllEXPORT).

Note that for v1.0.92, I had to remove the TOLUA_API that appears in toluabind.c:
int TOLUA_API tolua_tolua_open (lua_State* tolua_S)
int tolua_tolua_open (lua_State* tolua_S)

Update: For 1.0.93 with static linking, I didn’t have to remove anything like that. So don’t worry about this unless you get compiler errors.

Using Visual Studio 2005

The same comments as above (for vs2003) generally apply, although some minor tweaks need to be made.

Note that, due to VS’ poor c99 support, ‘toluabind.c’ in the “EXE” build will not compile. There are many lines that look like:

… int top; top = lua_gettop(tolua_S); static unsigned char B[] = { …

These need to be changed to:

… int top = lua_gettop(tolua_S); static unsigned char B[] = { …

or similar.

Tested with vs2005 (no service packs) and tolua++ 1.0.91.

Codereactor update: Had no problems like this in VS2008, so maybe this is not the problem at all anymore.

You can also download the precompiled executable from here: tolua++.exe precompiled executable download.

As for the precompiled library, I advice you not to bother. Tolua++ is just a couple of c files, just include them into the sources in your project, and forget about all that library inclusion hassle.

Embedding a scripting language in your own C++ programs

Wednesday, October 13th, 2010

One of my current projects has gained the critical mass complexity that can justify an embedding of a scripting language, so that some parts of the projects can be flexibly scripted instead of being hardcoded into the C++ code and thus require a time-consuming compilation every time anything changes.

After reading a little about this, I found out that there are a lot of options, and most of them are really easy!

My first idea was to have two different programs, one in C++ and the other one in PHP (but any other multipurpose script language would suffice), and make them communicate with each other. The best choice for communication would the TCP/IP sockets, and interface could be coded pretty easily. Each function that needed to be exported, could easily be mapped through the network code. Two different programs could even be located on different machines and easily connect through the net.

This solution is possible, and is not that bad actually, but it can get pretty annoying to have two different programs to run and maintain.

So there I came upon the Real solution.

The two script embedding options I liked the most were Lua and JavaScript engine spidermonkey.

Lua is an opensource scripting language, which is very easy to embed and is being used worldwide mostly in games to script the gaming logic. It’s biggest advantage is the speed. By checking different benchmarks, I found out that lua code can be just around 30 times slower than c++ code, which is VERY fast for a scripting language. (For comparison, php is like 300-400 times slower, perl is something like 100-300 times, and Java approx. 10 times).

With this speed, some pretty complex calculations could be easily done in lua, instead of being hardcoded. The other advantage is that lua is semantically extensible, which means that it has very few features out of the box, but you could easily implement almost any paradigm or design pattern, whichever is most suitable for your application.

For example, there are no classes in their usual meaning in lua, they are instead “implemented” in code. When using lua, you are not only writing programs, but also sort of create your own language as you go.

As for embedding, with a small additional opensource library (of mostly macros) Luabind, binding functions and classes of your c++ program to lua becomes a piece of cake. It almost comes down to 1 extra line of code per mapped function, really smooth.

The second option I am considering is JavaScript spidermonkey, which is an embeddable JavaScript engine from Mozilla.

It would be great to have JavaScript in my project, since it’s awesomely flexible, wide-spread and very easy to code in, having a common syntax. Also, for most web developers, JavaScript is a language where you know every class and every function already.

The downside is the speed (approx. 300-400 times slower than native) and the complexity. Also, since the language itself is much more complex than barebone lua, embedding it to applications and mapping functions and classes from c++ can sometimes be tricky and bloated with type conversions and argument checks.

So this seems to be the pro way to do it, so that’s what I am gonna do.  (This time it’s gonna be lua but I am eager to try the spidermonkey some time also).

PS. It’s a pity I have overlooked this at first, but apparently, boost (which you should use most of the time anyway, cz its awesome) has built-in python bindings which work almost as easy (sometimes even easier) than luabind. So that’s a great alternative also, especially if you are a python fan.