Visual Studio - popular, but a painful

[FluffyFreak]

@lwho, either gprof or by enabling the internal profiler would be great :)
I generally compile the profiler in by defining it in the preprocesser, or just in the header `Profiler.h`.

[FluffyFreak]

I did just update the PR, I have profiled it using the instrumented (built-in) one and it was consistently faster... but ingame it's an almost irrelevant amount.
I think I'd need to instrument up a specific test of the BVHtree generation to see a worthwhile difference and even then it will be an artificial test.

[robn]

On Linux you can configure with --enable-profiler and it will do the right thing.

[FluffyFreak]

Hah, super-fun times, a little birdy has informed me that VS2010 no longer builds because of <atomics>

He also gave me this handy link comparing C++11 features across vs2010 through vs2013 http://msdn.microsoft.com/en-us/library/hh567368.aspx

[FluffyFreak]

On Linux you can configure with --enable-profiler and it will do the right thing.

Of course on Linux GCC will do the right thing and there won't be any performance difference ;)

[lwho]

Hah, super-fun times, a little birdy has informed me that VS2010 no longer builds because of <atomics>

And, is this relevant? I explicitly asked, if we wanted to support any of the compilers that did not support atomics, when I made that change. And it was quite clear, they were supported from VS2012 only. No-one complained (see discussion in #2297).

He also gave me this handy link comparing C++11 features across vs2010 through vs2013 http://msdn.microsoft.com/en-us/library/hh567368.aspx

I used http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport that jbap mentioned in #2297 and which also includes non-MS compilers. However, any of these tables is useless, if we do not agree (and write it down on a good place) which minimum compiler versions of each we do want to support. http://pioneerwiki.com/wiki/Compiling might be a good place for writing it down.

[FluffyFreak]

It's just that the VS2010 solution is still in GitHub, but no-one active on the project uses it obviously which is why no-ones removed it either :)

He mentioned that he might try and get it working with boost.atomics as a fallback for vs2010 users who refuse to upgrade. So i'm going to leave the project in place for now and remove it if not.

[lwho]

I also just noticed, that there is a COMPILING.txt, which mentions even MSVC 2008, but not 2013. Seems to be a bit out of sync.

Linux: GNU Autotools with GCC or Clang
Windows: Microsoft Visual C++ 2008, 2010 & 2012
Windows: GNU Autotools with MXE (MinGW GCC) (cross-compile on Linux)
OS X: GNU Autotools or XCode 4

Maybe we can collect here, which are the current requirements. For GCC I'm sure, 4.6 is not working, 4.8 definitely is, so it's 4.7 or 4.8.

[robn]

Yeah, docs fall behind.

I don't think that "latest everything" is that bad. There's free versions of them all available. For people on XP, I hear Code::Blocks is working well now.

So GCC 4.8, MSVC 2013 (and 2012, I guess, you crazy Windows people).

[lwho]

I don't think that "latest everything" is that bad. There's free versions of them all available. For people on XP, I hear Code::Blocks is working well now.

So GCC 4.8, MSVC 2013 (and 2012, I guess, you crazy Windows people).

So, why MSVC 2012, if "latest everything"? I understand that there is a free version of 2013 as well, right? Or are there any Windows versions that are supported by 2012 and not by 2013? Both (last available free, more supported OS versions) would be valid reasons to keep 2012 support. Otherwise, I would vote for dropping 2012 as well, because even with 2013, MSVC still seems to be the compiler which is farthest behind in C++11 features, though not so much anymore.

Looking at the feature table, there are a lot of new features in 2013, where I yell "Oh yes, please, let me use it" (delegating constructors, deleted and defaulted member functions, non-static data member initializers, initializer lists); and especially one still woefully missing: constexpr.