Boost logo

Boost :

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.

Paul Mensonides

Boost list run by bdawes at, gregod at, cpdaniel at, john at