On 1 April 2016 at 23:52, Paul Mensonides
Standard. C++ code should not have to target any compiler at all.
Yes, it seems M$ agrees https://blogs.msdn.microsoft.com/vcblog/2016/01/22/vs-2015-update-2s-stl-is-.... It's pretty unclear what the problem is with the current state of affairs (vs2015U2), in respect of boost, old VC- and Clang-work-arounds intermingle with the new.
What all of the compilers that run on any platform (e.g. Windows: VC++, mingw, clang) should be doing is attempting to target the Standard, not copying each other's crap.
See above and work https://blogs.msdn.microsoft.com/vcblog/2016/02/11/compiler-improvements-in-... is ongoing. As to MinGW, msys https://blogs.windows.com/buildingapps/2016/03/30/run-bash-on-ubuntu-on-wind...is history (coming soon). There's even this https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-develo... in the making, and Clang https://blogs.msdn.microsoft.com/vcblog/2016/03/31/clang-with-microsoft-code.... Don't keep going on that it's all crap.
Unfortunately. Boost used to be a bastion of ingenuity and cutting edge practice. It is now mired in its own legacy of bending over backward (and forward) to support garbage.
Exactly, (at least) part of the problem lies here (sorry to trample on peoples toes, I have great respect for all of you experts). No longer required to support garbage, see above. Microsoft does not get to decide what C++ is. The C++ standard committee
decides that.
I'm sure Herb Sutter keeps them in the loop on this one.
Where VC++ is good or bad with respect to the conformance should be irrelevant to all other compilers.
And it could be, but where's libc++ for windows, f.e.?
The standard each of them is measured against is not each other but, well, the Standard. That breeds competition rather than lock-in, and it is that competition that provides the motivation that ultimately yields improved time frames.
From the links above, the message I get is that M$ has taken op that challenge. It seems the mountain is coming to Mohammad. Give W10 and vs2015U2 a try, and be honest when giving your feedback.
So, "untouchable" code written in the past was compiled by a compiler in the past. Where did that compiler go? It is not like every software project depends on all of the trillions of lines of code previously written in every other project ever.
Exactly, why does boost need to provide for let's say 'move semantics' for compilers that date back to 2002, it's just lunacy. Just use an old version of boost with an old compiler on an old code-base and stick it all in a VM and wrap the 'crap', as you call it, in a C-api. Moreover, why would you want to incorporate move semantics in a code base, that is apparently too old and too complex to update to "The Standard" anyway. All this bending over backwards inhibits progress. degski