I've become intrigued with the possibilities of std::function and std::bind as a more flexible way to handle function pointers. It seems to require compiling with g++ -std=c++11

What's the general opinion of c++11 these days? Is the spec well supported? Do you use it or avoid it? Can I expect any issues with compiling on the less common platforms (I'm mainly thinking of android)

The Android NDK ships with a pretty recent GCC, so you should be all set with C++11 support.

C++11 itself is great, it revolutionized how you can write C++. Move semantics and closures turned out to be amazing additions.

OK, I'll be the curmudgeon here. I think C++ in general is a design disaster chock full of half baked yet overly complex features, badly grafted onto C. C++ 11 does add a few "interesting" features. Lambdas are nice to have in any high level language, and move semantics for a workaround for the inherent problems of templates, references and classes, which you wouldn't need at all, if you had real OOP like in Objective-C, but I digress.

My experience with C++ has been invariably that once you start to us one of it's features you will need to use almost all of of it's features (use lambda's, now you need templates and classes too, etc), and then the accidental complexity will start hitting you badly. When you have to use C++ in a team, very often, people will try to use it in the most complex way possible because it makes them feel smart, which mean the code will become an unmaintainable mess of mostly wrappers around wrappers.

Furthermore, C++ isn't even forward portable. I wrote my first game in C++ 2.0 (before even C++ 98) and now it doesn't even compile anymore. With C++ 11 now, everything you did in C++03 is obsolete and you're suppose to rewrite everything using the latest and greatest, that is, until we get to C++17 when you will have to rewrite again. Allegro does still compile because it's written in the far more conservative C, apart from the DirectX interface with is in a fairly limite d subset of C++ (just C + classes, essentially).

For all these reasons I like to stick to plain C as much as I can, possibly enhanced with a scripting language. Another approach could be to use a severely restricted subset of C++ (like, say, Google does).

Finally I don't want to start a debate on C++, just tell you of my experience. Yours might differ. I'd say, try it out and find it out for yourself.

No disagreement here. I've played a bit with D too, and I like it much better. IMHO D strikes the right balance between language features and bare-to-the-metal. In work life I use Java and Groovy for everything, and D has some nice parallels with those languages.

However, I'm sitting on a large pile of my own legacy code in C++, and I'm never going to find the time to rewrite it all in a different language. So my question really is - given that I'm using C++, should I make the leap to C++11?

Forward compatibility is a problem - yes I had to fix a few things when adding -std=c++11, most notably clashes between boost and std namespaces. But given that I'm upgrading this code from allegro 4 to allegro 5, this was a small thing by comparison

I'd be interested to hear which engines you looked, and what your opinion is of them.

If you're using voxels or dynamic terrain of any kind, Unreal engine is not suitable if you want to use its collision/physics features. Collision data cannot be created during runtime. I just saved you about a minute of research.

Since Unreal engine is essentially the biggest Unity competitor right now (and is open source + 'free' for some definition of free), I'd thought I'd mention it.

For this work, I accept cash or check. My fair rate is hourly and equal to your country's GDP. Since it only took me 30 seconds at most to prepare the fact above, I will only charge 1/120th of my usual rate. Please note: if the check does not clear, then I will pursue legal action in the jurisdiction of my choosing. Thank you.

I personally love C++11 and will definitely make extensive use of it. I think by now the standard is old enough that all compilers of interest support it. Or rather, there is at least one compiler on all platforms of interest that supports C++11. "Platforms of interest" in my case are Windows, Linux and Mac, as well as possibly iOS and Android and - if I should ever even get that far - current gen platforms. Well, I'm not sure if PS4 and Wii U actually even support C++11, but I know that at least XBOX ONE supports, both, the STL and and C++11. I guess the other other two support C++11 code, too, but at least the Wii U doesn't seem to include the STL (I've searched for files including "namespace std" and got no hits). I think the Wii U only includes C libraries, anyways. Searching the PS4 SDK for "namespace std" got me several hits, though, so I suppose that one supports the STL as well. Just another hint at how outdated the Wii U is. It's by no means a bad system, but from my experience so far it's the least fun system to develop for, out of the three. Here is hope that this will improve for NX.

Anyways, I'm getting off track here. My point is this: I'm fine with C++11, as long as I'm only sticking to code that is actually covered in the standard, since I don't care too much about supporting out-dated compilers and the code should at least work on all systems that adhere to the standard. C++11 just added so many features that should have been part of the standard for a long time, anyways. For example, as already mentioned in a thread from a few days ago, the possibility to directly set the encoding of string literals (u8"" for UTF-8, u"" for UTF-16 and U"" for UTF-32). Since this wasn't really covered by any standard before (as far as I know), it was just so unreliable to use string literals in the first place. I also like the many improvements done to the STL, like containers using allocator_traits, which allows you to use allocators with states. This is actually important for me, since I want to have full control over memory (this is especially important on consoles), yet I also want to be able to use different allocators in different situations, want to keep track of each of them separately and want to be able to create new memory allocator instances at run-time, which can't work when allocators are forced to use global states.

These are just some of the things I appreciate about C++11. To be honest, I have only worked with it extensively for a few weeks now, so there are a lot of things I don't even know about C++11 yet, but so far, the more I learned about it, the more I appreciated it. Whatever problem I have in my engine, C++11 just always seems to have a solution for it.

I'm pretty much in the same situation right now. I've been working with Allegro 5 for several months this year, but first of all, I don't want to be stuck to Direct3D 9 or an out-dated OpenGL version forever. I eventually want to make an engine that runs in Direct3D 12 and Vulkan (with maybe adding D3D11 and OpenGL 4 ports later on for compatibility on older systems). Secondly, at some point, Allegro 5 just didn't really provide what I needed anymore. Allegro 5 was clearly written for 2D games with low to medium complexity in mind, with some neat new features that potentially allow for some more complex stuff (like shaders, vertex buffers etc.). However, I eventually got to a point where it really felt like Allegro lacked a lot of features I needed and where it felt like I always had to use a sledgehammer approach to get what I wanted. I still love Allegro, but I have gotten to a point where I need even more control over everything. Thirdly, having worked in professional game development for almost a year now, I have seen multiple engines and a lot of code that just gave me inspiration for my own engine, and I don't want to let that go to waste. That's why I eventually decided to write my own engine from scratch. It's only progressing slowly and it will probably take years before it actually gets somewhere (if I don't give up mid-way), but so far I'm still motivated, which is the most important thing for me.

TL;DR: C++11, yay, making my own engine, yay!

I see no reason to not use C++11 (or C++14) for any project of mine if I'm the sole or lead developer. It'd be like starting a new program with an old version of .NET.

One warning though is that C++14 (and maybe... c++11?) in GCC is actually slower to compile since the new features have not been optimized yet. And a few features are actually not supported... which I found out the hard way with something pertaining to threads.

I'm super excited to start playing around with std::future, std::promise, etc.

Well, I was referring to C++11 specifically. I have used C++ for a lot longer (several years by now, but especially extensively for the past year). I understand what you mean, though. C++ can indeed become a nightmare, depending on how it is used. I am currently working on a project where that is the case to at least some extent. It's a port of a last-gen title and the code at some places is just pure chaos. It has a lot of what you already described in a previous post, "wrappers of wrappers". Like, you try to figure out where a certain function is called in the code, but then you find out there is a wrapper function which does nothing but calling this function, so you have to consider that function as well. But then there is another wrapper for THIS function, so you get a nested construction that, at some point, gets so complex that you just have no idea anymore what happens where.

I do agree that C++ in general has many problems and dangers, but for me, the benefits have always outweighed these.

My C code doesn't compile as C++. For example, for some reason Stoustrup didn't and still doesn't understand that void* is supposed to be a generic pointer, as in, "you can store anything in it without a cast". For the rest, The few features I need are normally filled in by libraries like bstrlib, kthash, etc.

C doesn't like that either.

Right, but Who uses strict C89 anymore? or old C compilers? If you do anything particularly interesting with void pointers, compilers are a lot more strict these days.

Just move the deref to before the cast, should work.