Re: [boost] [clang][preprocessor] Testing of clang emualting the VC++ preprocessor on Windows

Subject: Re: [boost] [clang][preprocessor] Testing of clang emualting the VC++ preprocessor on Windows
From: degski (degski_at_[hidden])
Date: 2016-04-02 05:04:00

On 1 April 2016 at 23:52, Paul Mensonides <pmenso57_at_[hidden]> wrote:

C++ code should target the C++ Standard.  Compilers should target the C++
> 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-c17-so-far-feature-complete/>.
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-vs-2015-update-2/>
is ongoing. As to MinGW, msys
<https://blogs.windows.com/buildingapps/2016/03/30/run-bash-on-ubuntu-on-windows/>is
history (coming soon). There's even this
<https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/>
in the making, and Clang
<https://blogs.msdn.microsoft.com/vcblog/2016/03/31/clang-with-microsoft-codegen-march-2016-released/>.
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