Clang-cl.exe and the VC++ preprocessor

Dump the hyperbole. It is counter productive.

I am in the camp of people that want to move their msvc code to other realms. I am chiming in for political reasons. Our stuff is rudimentary C++ and we use as little of the host os abuse as possible. But you can barely do anything without interfacing to some important libraries.

It seems obvious that the minimum functionality is that you can compile and debug processes with clang that will run on windows. That to me implies being able to _LINK_ with platform libraries. To some extent that means you have to be able to digest their macros. But that is not the same as a wholesale emulation. I see no way around doing at least that much emulation.

Thanks!

Dump the hyperbole. It is counter productive.

I apologized for getting too emotional. However there is no hyperbole in the mere fact that when you use the VC++ preprocessor, or use clang-cl emulating some number of VC++'s preprocessor bugs, you may be producing preprocessor errors on perfectly valid preprocessor macros or, what is worse, you may be silently producing incorrect output from perfectly valid preprocessing macros.

This is why I am suggesting that while I understand that clang-cl needs to emulate VC++ preprocessor bugs in whatever respects in order to compile Microsoft header files it should do everything possible to implement C++ standard preprocessing for all other non-Microsoft header files with macros.

Surely no one wants to have a buggy preprocessor produce false errors or invalid output if it can be avoided.

The fact that the VC++ preprocessor can silently produce invalid macro output has never been acknowledged by Microsoft any more than the fact that their preprocessor does not follow the C++ standard. While the use cases where the VC++ preprocessor can cause errors or invalid output may be very small given the ways in which the large majority of C++ code use C++ macros, that use case does exist. Since I have worked extensively with such a library ( Boost PP ) and have developed another macro library ( VMD ), using some advanced preprocessor metaprogramming techniques which illustrate the bugs in the VC++ compiler, I am aware of their existence and the difficulty of writing such macro constructs with the idea of getting them to work with VC++'s non-standard preprocessor.

I am glad, as you say, that for "rudimentary C++" the preprocessing bugs of VC++, or clang-cl's emulation of those bugs, will not affect you and even a majority of C++ programmers. But there are some end-users who use and/or write macros who will be affected ( as in many Boost libraries ). It is for them I feel impelled to speak.

Hi Tom,

Dump the hyperbole. It is counter productive.

I am in the camp of people that want to move their msvc code to other
realms. I am chiming in for political reasons. Our stuff is rudimentary
C++ and we use as little of the host os abuse as possible. But you can
barely do anything without interfacing to some important libraries.

It seems obvious that the minimum functionality is that you can compile and
debug processes with clang that will run on windows. That to me implies
being able to _LINK_ with platform libraries. To some extent that means you
have to be able to digest their macros. But that is not the same as a
wholesale emulation. I see no way around doing at least that much
emulation.

Thanks!

(snip)

Today's Topics:

    1. Re: Clang-cl.exe and the VC++ preprocessor (Chandler Carruth)
    2. Re: Clang-cl.exe and the VC++ preprocessor (Edward Diener)
    3. Re: Clang-cl.exe and the VC++ preprocessor (Aaron Ballman)
    4. Re: Clang-cl.exe and the VC++ preprocessor (Edward Diener)
    5. Re: Clang-cl.exe and the VC++ preprocessor (Daniel James)
    6. Re: Clang-cl.exe and the VC++ preprocessor (Nico Weber)

(Snipped SIX. HUNDRED. LINES.)

Which of the above messages were you replying to?

You really should learn to use the delete key, especially when
replying to a digest.

Csaba

In article <lpu4k5$pu3$1@ger.gmane.org>,
    Edward Diener <eldlistmailingz@tropicsoft.com> writes:

The fact that the VC++ preprocessor can silently produce invalid macro
output has never been acknowledged by Microsoft any more than the fact
that their preprocessor does not follow the C++ standard.

Does anyone have connect bug report URLs so we can all go vote them up?

Wouldn't it be better in the long-run if MS fixed their preprocessor
so that we have i) a better built-in PP for MSVC and we can drop
workarounds in Boost.PP, and ii) less contortions we have to put into
clang in order to parse Windows header files?