About a year ago (rev. 799) we added the possibility to build PolyVox using the compiler's std:: C++0x header rather than depending on boost's. Then about 6 months ago David and I discussed whether or not this check was still really necessary given the state of modern compilers. At Uni I'm building PolyVox with GCC 4.1.3 which is about 2 years old now and it seems to have no problem with the C++0x stuff. I've no idea as to which Visual Studio versions build with ENABLE_CPP0X=ON though.

I'm wondering whether or not it's time to switch PolyVox to building in C++0x mode at least by default. For now we can always leave the option there to revert to boost (-DENABLE_CPP0X=OFF) but having the default doing something modern might be nice.

In related news, is boost only used for the C++0x compatibility stuff or is it used elsewhere as well? I.e. should I disable its installation when we're in C++0x mode?

_________________
Matt Williams
Linux/CMake guy

Actually I experimented with this only a week or two ago. I was trying to get PolyVox to build in C++0x mode on Visual Studio 2008 with SP1 - my understanding was that this was supposed to support the required C++0x features. Unfortunatly I didn't get it to work, and a search of my Visual Studio folder didn't indicate that I had any C++0x headers available. Maybe I did something wrong, or maybe there's a command line flag I have to set somewhere.

Anyway, Visual Studio 2010 is in Release Candidate status now and this is the version which should support C++0x properly. Once I pass my deadline at the end of the month I intend to wipe my machine and install newer versions of everything (Win 7, VS 2010, etc). At that point we can probably remove the Boost compatibility stuff completly and switch properly to C++0x.

In the meantime you can make C++0x the default if you like, as long as there is still the option to use Boost instead. And yes, Boost is only used for C++0x support. shared_ptr and the integer types such as int32_t I think.

If there is a compiler flag you have to set (and likely there is) then just add it to the ELSEIF(MSYS) section in the root directory's CMakeLists.txt (see the GNUCXX example the lines above). If there is no flag, then simply make sure the line is at least uncommented and setting C_PLUS_PLUS_ZERO_X_SUPPORTED (which is used in CPlusPlusZeroXSupport.h).


Ok. Once Visual Studio 2010 is released, I'll try compiling it with it too. I'm sure between us it'll be no trouble. There are also some nice features in CMake 2.8 which came out recently, I'm avoiding using them for now (and probably will continue for several months yet) but at some point I'll probably bump the version requirement.


Ok, I'll change the default but the option will remain like it is now. You'll simply need to set ENABLE_CPP0X to OFF and nothing should change.

_________________
Matt Williams
Linux/CMake guy

Yeah, I'm not sure if there is a compiler flag or not - I didn't really find any good information on it. But given that I couldn't find the headers I guess I'm not set up for it at the moment.

It's scheduled for release on 12th April, which should give me time to finish my work this month and prepare for the upgrade (I can update to Ogre 1.7 and Qt 4.6 before reformatting, in order to change one thing at a time). I'm assuming Microsoft will provide a free Visual C++ Express edition as they have done previously. And yes, well probably need a new version of CMake to support it.

As of rev. 1062 C++0x mode is enabled by default.


Yeah, I couldn't find any docs on it either.


I should be able to get a copy of 2010 via Microsoft Dreamspark. All previous versions have been available.

_________________
Matt Williams
Linux/CMake guy

Sounds good. In terms of bringing PolyVox up to date I also intend to change the OpenGL example to do things the OpenGL 3.2 way. Or at least remove support for the very outdated 'immediate mode'. I put this in to support really old graphics cards, but even MesaGL supports index/vertex buffers now. I think making the example simple to follow should be more important really.

Yeah, I guess it's important that it's a PolyVox example and not an OpenGL one

_________________
Matt Williams
Linux/CMake guy