Migrating from Boost 1.35 to TR1

Just porting some stuff over to TR1, here some things that you need to take care of:

  • For easy migration, prefer to use the boost/tr1/ headers, as they provide a fall-back to Boost if TR1 is not available.
  • std::tr1::function has no empty () function, use if (function_object) instead.
  • std::tr1::tuple has no get member function, use std::tr1::get<0> (tuple_instance) instead. For some reason or another, no ADL is possible here.
  • boost::bind provides the placeholders _1, _2, etc., while std::tr1::bind doesn't -- I'd stick with boost::bind as the _1 placeholders are very convenient.
  • There is no scoped_array, shared_array in <memory> -- use Boost for this.

Visual C++ feature pack

Microsoft released the Visual C++ feature pack, which brings an updated MFC and -- the best part -- TR1 support to C++! No more looking for std::tr1::shared_ptr or std::tr1::unordered_set. Woho! Only problem is the installation currently fails if you are using a non-english Windows, the workaround is quite simple though: Go to the language options and set the format to English, and the location to USA. No need to change the UI language itself (on Vista).

Experiences

Well, the semester break is nearly now, time to look back at the last half year. I tried and used quite a few new things this time (Tried and used means usually I wrote something non-trivial with it. After all, the following list is the sum of 6 months of programming ;) ):

  • Ported a fairly large project over to CMake (from MSVC++). Took me quite some time, but I became pretty familiar with CMake in exchange. The build process included lots of dependencies, pre- & post-build steps and various custom configuration points and didn't work until 2.6 beta due to a bug in 2.4.8. Looking forward to use it in the future for more projects.
  • Some parallel programming with OpenMP and profiling with Intel VTune/Thread Profiler. Worked quite well actually, included reworking an algorithm for better scalability and implementing it.
  • Lots of Java programming: Wrote a compiler with it (from scratch) and some smaller side projects. It's not as bad as it used to be (last time I used Java was around 1.2), but I fear I won't love it anytime soon ... except for the top-notch refactoring capabilities of Eclipse/Netbeans.
  • DirectX9, programming and debugging with PiX. Basically, the last several months I've been using DX9 and I must admit it's a pretty comfortable development environment (at least, compared to OpenGL -- PiX' "debug this pixel" is just great).
  • Boost -- I've learned how to get Boost running from SVN directly (during the time VC9 was not supported officially) and I had a chance to take a look at the new thread stuff. The latter is pretty interesting as it's the same that will be part of C++0x, the earlier you take a look at it the better.

[Update] Yeah, I know, the about page does not reflect this -- I gotta update it some day, but I doubt I can ever keep it really up-to-date. Also note that this list is not really complete.

Boost 1.35 released

Boost 1.35 has been finally released. Highlights include:

  • Rewritten Boost.Thread to closely match the C++0x Thread library, and with native_handle () support. Works great, I already ported a project to it, so far no problems. Includes also synchronisation primitives like conditions.
  • Boost.Asio: Networking in Boost!
  • Boost.Interprocess: Shared memory, memory-mapped files, etc.

Moreover, some very interesting libraries like the Generic Image Library GIL (from Adobe) have been added, but I didn't have a chance to try them. Compiled fine with VC9/Vista for x64 & x86 (see also how to compile Boost with VC9 for x86 & x64)

Building OpenEXR 1.4.0a on Vista/VS2008

Some notes for building OpenEXR 1.4.0a on Vista with VS2008:

  • createDLL won't work as it tries to create files in C:\. You can easily work around this by replacing C:\\ with a path where you have write rights.
  • FLTK include files have to be directly in the fltk folder. The fltk folder needs to be placed side-by-side to the OpenEXR folder.
  • Using multi-threaded building won't wont, so make sure you either batch-build or set your "maximum number of parallel project builds" to 1.

Observing this and the readme notes, I was able to successfully compile all but the exrdisplay with Cg support, which is no wonder as I don't have Cg installed.