Using -std=c++11 with the macports gcc-4.7 compiler

[Ryan Schmidt]

On Jan 16, 2013, at 19:49, Sean Farley wrote:

> On Wed, Jan 16, 2013 at 7:16 PM, Jeremy Huddleston Sequoia wrote:
>> 
>> That being said, is there something wrong with clang++ that is causing you to try g++ instead?
> 
> Jeremy, please understand that this is a frustrating position / stance
> to have from the perspective of the user. In the scientific community,
> it is *expected* to try out all the compilers you have access to.
> Usually, this just means Intel, Portland Group, IBM, and gcc; but now
> it also includes clang. Also, there are _tons_ of reasons that
> projects use different compilers. The most common is fortran (don't
> even get me started on Apple stripping out gfortran from gcc 4.2 AND
> THEN providing a bogus mpif{77,90} wrapper). If your project has both
> C++ and Fortran dependencies, then the only way to compile the Fortran
> is to install gcc4X. Well, that usually means your configure script
> will also pick up gcc4X's C/C++ compiler.
> 
> The second most common reason I've seen is the one you mention: errors
> in the C++ compiler. If Apple decides to update their Xcode clang
> version to 3.1 or later anytime soon, then everyone on a mac will run
> into this bug,
> 
> http://llvm.org/bugs/show_bug.cgi?id=14768
> 
> I personally have had clang++ bugs with libmesh, moose, armadillo, and
> dolfin. What makes this sentiment frustrating is the whole "use this
> one version of the library with no optimization or debug control"
> which is at odds with "try this library with {gcc,clang,etc.}'s
> -O{1,2,3} and then write a paper about the results." This actually was
> my whole motivation for writing scienceports: provide a way to use a
> library with gcc4X or clang3X and somehow manage the combinatorial
> explosion of variants (the correct data structure, by the way, is a
> DAG).
> 
> Ok, this rant is too long now. I hope no one is offended as I tried to
> explain some of the science community's frustration.

That's a valuable and valid viewpoint, and a totally reasonable answer to Jeremy's question. The need or want to compile some programs with different compilers or different compiler settings is a valid reason not to use clang. I'm guessing only a minority of our users are interested in that, and that only a minority of software would significantly benefit from such optimization, but that doesn't make it unimportant.

But we must also understand Jeremy's viewpoint. You can see from his email address where he works. Clang is the compiler that OS X will use from now on; Xcode does not come with gcc anymore. So Apple clearly wants as much software to be compilable with Clang as possible, and wants to fix any bugs that are found with regard to that.