So basically something in your code is screwing around with memory.

Either releasing something that has already been released:

int* x = new x[10];
delete [] x;
delete [] x;

Or releasing something that is not pointing to the start of an allocated block of memory:

int* x = new int[10];
x++;
delete [] x;

The error message isn’t very clear if you have no experience with GDB. GDB is a debugger for your binaries. It allows you to set break points at the start of a function and any time that function is called your application will pause and allow you to debug in GDB. We can then get valuable information back by executing commands to get the backtrace, registers state and disassembly. The advantage of using GDB over Xcode/KDevelop is being able to break into any function, not just functions in your source code. Anyway, this is how I got the backtrace to find out where in my sourcecode I was making a mistake:

gdb
file myapplication
break malloc_error_break
run
backtrace

Now whenever a double free or non- aligned pointer is freed it will break into gdb and we can type in “backtrace” and work out what our code did to trigger this.

I’ve just created a very small C++ wrapper (libxdgmm) for accessing XDG more easily. To use it, you need libxdgmm.h and libxdgmm.cpp. Just add these to your project and then use them like so:

#include <libxdgmm/libxdg.h>
 
int main(int argc, char** argv)
{
  if (!xdg::IsInstalled()) std::cout<<"XDG is not installed"<<std::endl;
  else {
    std::string data;
    xdg::GetDataHome(data);
    std::cout<<"data=\""<<data<<"\""<<std::endl;
 
    std::string config;
    xdg::GetConfigHome(config);
    std::cout<<"config=\""<<config<<"\""<<std::endl;
 
    // Obviously these have to exist to work.  You can translate the error code returned by calling xdg::GetOpenErrorString(int result);
    xdg::OpenFile("/home/chris/dev/cMd3Loader.cpp");
    xdg::OpenFolder("/home/chris/");
    xdg::OpenURL("http://chris.iluo.net");
  }
 
  return EXIT_SUCCESS;
}

I still have to wrap some of the other functionality, such as XDG_DESKTOP_DIR, XDG_DOCUMENTS_DIR, XDG_MUSIC_DIR, desktop-file-utils, xdg-desktop-menu and xdg-desktop-icon etc. I will wrap these as I need them (Or at special request). I don’t think I will be supporting xdg-screensaver or xdg-mime as I don’t have a use for them right now.

boost/filesystem/operations.hpp

661	661	    inline bool is_empty( const path & ph ) 
662	 	-      { return is_empty<path>( ph ); } 
 	662	+      { return boost::filesystem::is_empty<path>( ph ); } 
663	663	    inline bool is_empty( const wpath & ph ) 
664	 	-      { return is_empty<wpath>( ph ); } 
 	664	+      { return boost::filesystem::is_empty<wpath>( ph ); }

The full patch is much longer, but this seemed to be all I needed to get it to work (Note: You will need to su and then gedit /usr/include/boost/filesystem/operations.hpp).

Anyway, you will want to test it out:

enum A
{
  A_1,
  A_2
};
 
enum B
{
  B_1,
  B_2
};
 
void Test()
{
  B b = 0;
 
  b = true;
  b = 1;
  b = A_1;
  b = A::A_1;
  b = B_1;
  b = B::B_1;
}

The only lines of Test that compile are “b = B_1;” and “b = B::B_1;”. Under C++98/C++03 this would 100% compile, which could easily create bugs where the code compiles but may not be what is intended. We can also get slightly tighter restrictions again, by defining “enum B” as “enum class B”. This restricts the correct lines of Test to “b = B::B_1″, meaning the enum must be fully qualified which should lead to less ambiguous code. In a real situation you will also want to actually initialise b to a decent value initially as well: “B b = B::B_1″ for example.

Anyway, this is a pretty trivial example, just a tidy up of the language really, you will want to delve deeper. Variadic templates, Initializer lists, Lambda expressions and closures, New character types, Unicode string literals, Raw string literals and Universal character name literals look good. Extern templates, Inheriting constructors, nullptr, __func__, C99 preprocessor, long long, Extended integral types can’t get here soon enough.

Skysytem background, testing wireframe grid, TombRaider MD3 model, testing material boxes, particle systems, frames per second messages, pegs, shocks, all the necessary elements of a Sudoku game.

It’s been a while, I have like 20 draft entries in WordPress ranging from 1 paragraph comments up to 10 paragraph full on entries that still need that final once over and edit before going live. Actually it might be cool if there was (There probably is) a plugin so that people could optionally go to a page on my blog where they can see everything that hasn’t been published yet, like tagged with “draft” or something and comment on which ones I should flesh out and which ones I should ditch before they are even finished.

Anyway, so I have been working (Getting side tracked while working on) my Sudoku game.

Basically in Sudoku mode you get to select a number from the “palette” at the top and then click on all the places you want it on the board. The solver I have coded up can solve about 80% of Sudoku boards with “human solvable” methods and the remaining 20% can be solved with a combination of human solvable and then resorting to brute force for anything it can’t find. A valid board should not need brute forcing which means that I need to implement more rules for my human solving methods first. I should be doing something like this:

if (solve_human_methods()) ... solved
else ... this board is invalid as it could not possibly be solved by a human without resorting to brute force

However I haven’t implemented all human methods of solving yet, only about 4 or 5 simple ones, actually probably less, there are about 2 or 3 real rules and then 4 or 5 extrapolated rules that are just combinations of the first ones.

Anyway, in First Person mode there is flying around (No clip mode) as well as moving Lara Croft around (Optionally other MD3 models) with sort of appropriate animations based on velocity (But not facing direction yet). One thing I have noticed is that half of the MD3 models I download have different file naming conventions, so at some stage I want to break out some Quake 3 action and see what file names it uses and use that as my standard.

Why all this other stuff in a Sudoku game? Whichever game I am working at the time becomes my test bed application for whatever I feel like implementing when bored. I really need to make a dedicated test bed that does nothing else but demonstrate stuff. I’ve also split my game engine into Spitfire and Breathe portions, which splits the library into two halves, the generic tools for any application (string, math, xml, md5 hashes etc.) and game specific features (OpenGL rendering, audio, physics, MD3 animation, etc.) respectively.

However, don’t go the websites, all of these are available in the (Default?) repositories, so you can either install them via yum, PackageKit or apt-get. Also note: RapidSVN and Meld are only needed if you want to use SVN. Even KDevelop is not required if you have another text editor that you prefer such as gedit/vi/emacs. If you want to create your provide your own make file then you don’t need cmake either.

Anyway, so a simple application that just tests that you can do a 64 bit compile is pretty straight forward.
1) Create your main.cpp file with a int main(int argc, char* argv[]); in it.

# Set the minimum cmake version
cmake_minimum_required (VERSION 2.6)
 
# Set the project name
project (size_test)
 
# Add executable called "size_test" that is built from the source file
# "main.cpp". The extensions are automatically found.
add_executable (size_test main.cpp)

2) Create a CMakeLists.txt that includes your main.cpp.

#include <iostream>
 
int main(int argc, char* argv[])
{
  int *int_ptr;
  void *void_ptr;
  int (*funct_ptr)(void);
 
  std::cout<<"sizeof(char):        "<<sizeof(char)<<" bytes"<<std::endl;
  std::cout<<"sizeof(short):       "<<sizeof(short)<<" bytes"<<std::endl;
  std::cout<<"sizeof(int):         "<<sizeof(int)<<" bytes"<<std::endl;
  std::cout<<"sizeof(long):        "<<sizeof(long)<<" bytes"<<std::endl;
  std::cout<<"sizeof(long long):   "<<sizeof(long long)<<" bytes"<<std::endl;
  std::cout<<"------------------------------"<<std::endl;
  std::cout<<"sizeof(float):       "<<sizeof(float)<<" bytes"<<std::endl;
  std::cout<<"sizeof(double):      "<<sizeof(double)<<" bytes"<<std::endl;
  std::cout<<"sizeof(long double): "<<sizeof(long double)<<" bytes"<<std::endl;
  std::cout<<"------------------------------"<<std::endl;
  std::cout<<"sizeof(*int):        "<<sizeof(int_ptr)<<" bytes"<<std::endl;
  std::cout<<"sizeof(*void):       "<<sizeof(void_ptr)<<" bytes"<<std::endl;
  std::cout<<"sizeof(*function):   "<<sizeof(funct_ptr)<<" bytes"<<std::endl;
  std::cout<<"------------------------------"<<std::endl;
  std::cout<<"Architecture:        "<<sizeof(void_ptr)<<" bit"<<std::endl;
 
  return 0;
}

3) cd to the directory of your CMakeLists.txt and run “cmake .” and then “make”
4) ./size_test output:

sizeof(char):        1 bytes
sizeof(short):       2 bytes
sizeof(int):         4 bytes
sizeof(long):        8 bytes
sizeof(long long):   8 bytes
------------------------------
sizeof(float):       4 bytes
sizeof(double):      8 bytes
sizeof(long double): 16 bytes
------------------------------
sizeof(*int):        8 bytes
sizeof(*void):       8 bytes
sizeof(*function):   8 bytes
------------------------------
Architecture:        64 bit

As you can see this is specific to x86_64. The beauty of gcc is that by default it compiles to the architecture it is being run on. I had previously thought that it would be a world of pain, making sure that my compiler built the right executable code and linked in the correct libaries. I know this project doesn’t use any special libraries, but (because of cmake?) the process is exactly the same as using cmake under 32 bit to make 32 bit executables. You just make sure that they are there using Find*.cmake and then add them to the link step:

SET(LIBRARIES
  ALUT
  OpenAL
  GLU
  SDL
  SDL_image
  SDL_net
  SDL_ttf
)
# Some of the libraries have different names than their Find*.cmake name
SET(LIBRARIES_LINKED
  alut
  openal
  GLU
  SDL
  SDL_image
  SDL_net
  SDL_ttf
)
FOREACH(LIBRARY_FILE ${LIBRARIES})
  Find_Package(${LIBRARY_FILE} REQUIRED)
ENDFOREACH(LIBRARY_FILE)
 
# Link our libraries into our executable
TARGET_LINK_LIBRARIES(${PROJECT_NAME} ${LIBRARIES_LINKED})

Note that we don’t actually have to specify the architecture for each package or even the whole executable. This is taken care of by cmake. Anyway, it is not some mysterious black magic, it is exactly the same as you’ve always been doing. Cross compiling is slightly different, but basically you would just specify -m32 and make sure that you link against the 32 bit libraries instead. If I actually bother creating another 32 bit executable in my life I’ll make sure that I document right here exactly how to do a cross compile from 64 bit.

The advantages of 64 bit are mmm, not so great unless you deal with really big files/memory ie. more than 4 GB. Perhaps more practical are the extra and upgraded to 64 bit registers so you may see an increase in speed or parallelisation of 64 bit operations, for example a game may want to use 64 bit colours (ie. 4x 16 bit floats instead of 4x 8 bit ints to represent an rgba pixel.

Things to watch out for:
int is still 32 bit! If I were implementing the x86_64 version of C++ standard/gcc/in a perfect world this would have been changed to 64 bit, ie. “int” would be your native int size, it’s logical, it makes sense. However, I do understand that this would have broken a lot of code. The problem is, if int != architecture bits, then why have it at all, why not drop it from the standard and just have int32_t and int64_t and be done with it. Then if a program chooses it can have:

typedef int32_t int;

or

typedef int64_t int;

as it sees fit. Anyway.
Pointers are now 64 bit! So you can use them with size_t but cannot use them with int
Under linux x86_64 gcc sizeof(int*) == sizeof(function*), however, this is not guaranteed anywhere. It may change on a certain platform/compiler. Don’t do stuff like this:

int address = &originalvariable;

gcc should warn you (you may need to turn on these warnings -Wformat -Wconversion).

All in all, if you have been writing standard code and using make/cmake it should be relatively pain free to upgrade to 64 bit.

int GetValue0()
{
  return 10;
}
 
int GetValue1()
{
  return 10 + 10;
}
 
int GetValue2()
{
  return 10 * 10;
}

So if all of the values 10 represent a common magic number then you are going to want to extract that value to one location instead of the 5 that it is in at the moment. How do we do this?

Say we call the value MAGIC_NUMBER (Of course, in a real life situation you would use a better name than this, wouldn’t you? Something like PI, GST_PERCENTAGE, NUMBER_OF_CLIENTS, etc.) we would then have this code.

Example B:

int GetValue0()
{
  return MAGIC_NUMBER;
}
 
int GetValue1()
{
  return MAGIC_NUMBER + MAGIC_NUMBER;
}
 
int GetValue2()
{
  return MAGIC_NUMBER * MAGIC_NUMBER;
}

Great. The problem now is, how do we tell our program about MAGIC_NUMBER?

If you originally started programming C then your first instinct may be to use:

#define MAGIC_NUMBER 10

The main problem here is that the compiler may not realise that all of the places you use MAGIC_NUMBER are linked so it may not realise that it can factor it out. The other problem with this method is the lack of type safety. You can use MAGIC_NUMBER with sign/unsigned ints, char, bool etc. The compiler may not warn you about converting between these types. For an int this isn’t really a problem, but const float PI = 3.14…f should give you a warning when you try to initialise an int to it. This is good news as it requires you to cast if you really want to do it, which then shows other programmers than you have actually thought about what you are doing and what is happening to the value as it passes through each variable.

You might be tempted to use:

int MAGIC_NUMBER = 10;

This is much better as it adds type safety, however you can do even better than that,

const int MAGIC_NUMBER = 10;

This way it isn’t “just” a global variable, when you declare it as const you are telling the compiler that it will never change in value which means that it can make all sorts of assumptions about how it will be used. Your compiler may or may not factor out/in this value, it may or may not insert 10 + 10 and 10 * 10 into those functions for you at compile time. Using a const int means that the compiler gets the choice of using either the value directly or using a variable containing that value, and I trust the compiler more than myself to make that decision. Because it knows the value of MAGIC_NUMBER at compile time and knows that it will never change at runtime it can actually do the calculation and insert that value instead.

int GetValue0()
{
  return 10;
}
 
int GetValue1()
{
  return 20;
}
 
int GetValue2()
{
  return 100;
}

The other magic number container is enum. It varies slightly to const int as it is more for collections of values where you want to identify something by what type it is.

enum RESULT
{
  RESULT_FILE_DOWNLOADED,
  RESULT_CONNECTION_FAILED, 
  RESULT_FILE_NOT_FOUND,
  RESULT_DISCONNECTED
};
 
RESULT DownloadFile(const std::string& url)
{
  // Pseudocode
  if (could not connect) return RESULT_CONNECTION_FAILED;
  if (file not found) return RESULT_FILE_NOT_FOUND; 
 
  if (disconnected) return RESULT_DICONNECTED;
 
  return RESULT_FILE_DOWNLOADED;
}

In this way we can get rid of magic numbers and (In C++0x at least with enum class) get some type safety, your compiler will hopefully complain if you try and return an integer instead of a RESULT.