Re: [boost] C++ announcements coming tomorrow

Subject: Re: [boost] C++ announcements coming tomorrow
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-11-04 16:16:12

On 11/4/2012 12:33 PM, Matt Calabrese wrote:
> On Sun, Nov 4, 2012 at 3:01 PM, Edward Diener <eldiener_at_[hidden]>wrote:
>
>> I doubt if Microsoft considers full support for C++(11) to be also
>> producing a compliant preprocessor. I am not defending them for that
>> viewpoint but it does seem as if they view the preprocessor has a separate
>> part of the C++ language which they do not have to implement according to
>> the latest C/C++ standards.
>>
>
> I think the problem is that so few people care about a compliant
> preprocessor, and those who do care are often library developers who
> consistently bend over backwards with workarounds to support VC++ anyway.
> That coupled with the fact that fixing their preprocessor means potentially
> breaking people's code (even though it was noncompliant to begin with),
> means that it is an extremely low priority for them. IMO, they should just
> include something like Boost.Wave or Clang's preprocessor and have a
> compiler option to enable it (even if it defaults to not being enabled,
> falling back to their noncompliant preprocessor) and make sure that windows
> headers compile correctly with it on. I can't imagine that this would be
> too difficult for them to do, and at least then library developers have
> some way to support VC++ without tons of workarounds -- just tell users of
> the library to pass in the appropriate compiler option.

There are certainly features of the language which are more important 
than the preprocessor.  However, the preprocessor has been broken for 
decades.  More than that, in comparison to many other language 
facilities, implementing it correctly is easy.  The problem is not that 
it is a low priority among language features.  The problem is that other 
things such as extensions and integrated libraries are prioritized ahead 
of language features/bugs--and new instances of those keep occurring so 
the end of the priority list never gets reached.  In the specific case 
of the preprocessor and some others, the problem is that it is 
continuously classed as "won't fix" and therefore has no priority at all.

I would be much happier with a priority list that was something like:

1. C++ feature A
2. C++ feature B
3. C++ bug 1
...
100. C/C++ preprocessor
101. language extensions for AMP
102. language extensions for C++/CLI/CX

I would be actually happy with a priority list that was something like:

1. C++ feature A
2. C++ feature B
3. C++ bug 1
...
100. C/C++ preprocessor

with language extensions for AMP, C++/CLI, and C++/CX not existing at 
all and instead implemented entirely as libraries.  In that case, the 
compiler would not be dependent on the development of these things and 
therefore these things could be developed concurrently by separate teams 
and have their own priority lists.

However, both of the above priority lists are *far* away from what 
actually appears to occur.  Instead, it is more like

1. C++ bindings to WinRT (marketing driven)
2. C++ bindings to C++/CLI (marketing driven)
3. C++ subsetting/extensions for AMP (marketing driven ultimately for 
cloud services)
4. new C++11 features (actually also marketing driven)
5. feature-breaking bugs

Almost everything else is classified as "won't fix."

Worse than the above, (1), (2), and (3) get implemented and taken off 
the list only to be replaced by new marketing-driven, extra-linguistic 
concerns.  The result is excessively slow adoption of C++11 features and 
almost no adoption of missing C++98 features or fixing of 
mis-implemented C++98 features.

Virtually every action taken by MS WRT VC++ is contrary to what Herb 
repeatedly says in his various talks and interviews.  MS is free to do 
whatever they want.  However, stop lying to us and stop playing politics.

Regards,
Paul Mensonides