future-proof

I'm considering writing what is essentially my first parser since forever (= since the compiler class at Uni which I've forgotten mostly). Since I use C++, I was thinking of using Boost Spirit. Then I noticed there's the "regular" 2.5.2 and there's something magical subset of the code named Spirit X3. I' also ve noticed that Boost Spirit X3 was announced/discussed/pre-released already 2 years ago, yet Boost Spirit's official version is 2.5.2. Finally, I read: Where is boost-spirit 3? Is it abandoned? So I "know" that it's not an abandoned project - but not a very actively maintained project.

Writing my code for Python 2.6, but with Python 3 in mind, I thought it was a good idea to put from __future__ import unicode_literals at the top of some modules. In other words, I am asking for troubles (to avoid them in the future), but I might be missing some important knowledge here. I want to be able to pass a string representing a filepath and instantiate an object as simple as MyObject('H:\unittests') In Python 2.6 , this works just fine, no need to use double backslashes or a raw string, even for a directory starting with '\u..' , which is exactly what I want. In the __init__ method I

Which is preferred boost::lock_guard or boost::mutex::scoped_lock ? I'm using Boost.Thread with the hope to move to C++11 threading when it becomes available. Is scoped_lock part of the next c++ standard? Are the any advantages to prefer one over the other? NOTE : I'm aware that scoped_lock is just a typedef of lock_guard . edit: I was wrong scoped_lock is not a typedef of lock_guard . It's a typedef of unique_lock . Amit is right: boost::mutex::scoped_lock is a typedef for boost::unique_lock<boost::mutex> , not lock_guard . scoped_lock is not available in C++0x. Unless you need the

There are already two compilers that support C++ modules: Clang: http://clang.llvm.org/docs/Modules.html MS VS 2015: http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx When starting a new project now, what should I pay attention to in order to be able to adopt the modules feature when it is eventually released in my compiler? Is it possible to use modules and still maintain compatibility with older compilers that do not support it? There are already two compilers that support C++ modules clang: http://clang.llvm.org/docs/Modules.html MS VS 2015: http://blogs

All the Python built-ins are subclasses of object and I come across many user-defined classes which are too. Why? What is the purpose of the class object ? It's just an empty class, right? In short, it sets free magical ponies. In long, Python 2.2 and earlier used "old style classes". They were a particular implementation of classes, and they had a few limitations (for example, you couldn't subclass builtin types). The fix for this was to create a new style of class. But, doing this would involve some backwards-incompatible changes. So, to make sure that code which is written for old style