"When you wish upon a star it makes no difference who you are, your
dreams come true." <g><g> !

My sense of humor comes out when I think that the technical know-how of
even very good programmers is going to change the motivation of the
richest software company in the world to do anything technically that
does not increase its profits in the long run. This is not a knock on
Microsoft per se but just an acknowledgment of the reality of capitalism
in the world I live in. You have to prove to them that by not doing
something correctly which they have done in their own way which
apparently "works" for them that they will lose customers ( developers
in this case ). Considering that Visual Studio is almost certainly the
most popular development environment for Windows programming and that
there is probably less competition in that area than there has ever
been, I have a hard time seeing this happening. Of course if a C++ guru
like Herb Sutter makes this happen, all the better, but haven't we all
heard this sort of thing before ?

>
>>> This wait will not be what *you* want, of course!
>>
>> What I do not want is to have to try to hack Boost PP in order to make clang
>> targeting VC++ work. To clang's credit when I ran the Boost PP tests, which I
> have
>> largely expanded, in the 'develop' branch against the clang VC++
> implementation,
>> only a single test failed due to clang emulating VC++ preprocessor bugs.
>>
>> I have argued vehemently in the clang developer mailing list that, although I
> do now
>> understand that clang targeting VC++ has to emulate some of VC++'s
> preprocessor
>> bugs in order to compile the VC++ header files, clang targeting VC++ should
>> otherwise be a C++ standard conforming preprocessor for all other code. This
> could
>> be done pretty nicely via a pragma. But it does not seem to have made much of
> an
>> impression on others there. Many clang developers/users are so happy that they
> can
>> use clang in place of VC++ in the VS IDE that they cannot understand what a
> poor
>> C++ preprocessor VC++ is when one goes beyond fairly simple macro expansion
>> techniques, as of course Boost PP does.
>
> I think you may appear to the Clangers to be a 'lone' (perhaps loony? ;-) PP
> enthusiast.

Most probably. But on a practical basis many Boost libraries use Boost
PP so if there are problems in Boost PP for a particular compiler it
could easily affect an end-user's ability to use a Boost library. That
was my larger concern with arguing about clang for VC++'s unfortunate
consequence of emulating VC++ preprocessor bugs.

>
> Can we produce any collective Boost wish to help this to happen?
>
> Although it is a can of worms, there must be some way to meet peoples needs, as
> you explain above.

I made my pitch on the clang developers mailing list for a pragma to
control either correct or VC++-like macro expansion. I also said for
myself, in no uncertain terms, that I am not willing to hack Boost PP
further for a compiler which emulates some subset of VC++ preprocessor
bugs. I highly doubt if Paul Mensonides will either. Even if VC++ were
to announce that starting this minute their latest VC++ implementation
has a completely C++ standard-conforming preprocessor, I am sure clang
using VC++ would still support the emulation bugs they have incorporated
in it in order to support already existing versions of VC++.

My own point of view regarding clang in Windows is that their use of
gcc/mingw works fine and I have little practical use for substituting
clang in place of VC++ in the Visual Studio IDE.