| The question is, how do I easily call the new C++11 code from something like Lua, Java, Python, Ruby, etc.? How weird will my wrapping code end up looking? Well, no weirder at least than the older C++. Which is certainly a matter of perspective! :-) In the ideal case, someone will write a C++ binding to your language that's even easier than C. Like I said, some people love Boost.Python but I haven't tried it. I did play with Lua and C++ recently. The Lua interpreter itself can be compiled as C++! It will then throw C++ exceptions instead of using setjmp/longjmp, which is much saner IMHO. (I am really impressed with Lua.) Just a feeling, but I bet that sooner or later somebody is going to come along and do something really cool with C++11 lambdas and that multi-language bindings problem. I'm sorry to harp on this, but I'm in the middle of a medium-size engine codebase written in C++, and even with our restraint so far on the use of some of the more advanced language features, things like smart pointers and whatnot are so useful that they become a concern (multithreaded code without smart pointers is a recipe for madness). Yeah. How does one code without smart pointers in their toolkit? I couldn't go back..(except when I have to thunk back to C for something). Also, for multithreaded stuff, I'm getting addicted to the new std::atomics in C++11! Not new with C++11, but have you tried Boost.ASIO for multithreaded IO? It is awesome. Out of curiosity, how much have you done with OpenGL/OpenAL/OpenCL, etc.? Have you had any issues there yet? I'd like to know if that stuff fits okay with C++11. I have, in fact, been doing some experiments with C++ and OpenGL in my spare time. Made some wrapper classes for compiled shaders and buffer objects and the like. I had much of that code running before I switched to G++4.6.0 and starting allowing myself to depend on C++11 features, but I know I've extended it some since. I really don't recall noticing any difference in the switch. One of the biggest advantages of C++ is something that many people miss. Much of that "ugly" complexity is in support of some design principles that are critical for large-scale software development: backwards compatibility (often back to C), and you don't pay for new features you don't use. |