I suggest you ...

Stop treating workarounds as a legitimate alternative to standards compliance

Particularly in the world of C++, where the delta between what the compiler accepts and what the standard says is quite large, it is common for people to report bugs against the compiler.

Often, however, these are met with refusals to fix the compiler, and claims that there are workarounds.

I would love you to change this policy.

Yes, sometimes there is a zero cost workaround to a particular flaw. But that's not a reason to not fix the bug. I write code that I wish to compile in g++, VC++, and sometimes even clang++. Being forced to avoid standard constructs just because they provoke a VC++ bug is aggravating in the extreme.

Please stop treating workarounds as if they were good enough. We want to be able to use the best possible C++ compiler.

242 votes
Vote
Sign in
(thinking…)
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
DrPizza shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

6 comments

Sign in
(thinking…)
Password icon
Signed in as (Sign out)
Submitting...
  • Marián Špánik commented  ·   ·  Flag as inappropriate

    Here is one example of workaround treated as a legitimate alternative to standard's compliance:
    https://connect.microsoft.com/VisualStudio/feedback/details/860388/in-c-std-clock-returns-wrong-value
    If I were you I would make the clock() return what it should with maintaining previous non-conformant behaviour when some preprocessor definition is set (#define before including time.h or in project setting). At present this causes hard-to-find bugs when porting code from/to another compiler.

  • Alex commented  ·   ·  Flag as inappropriate

    Both GCC and Clang have already implemented the complete C++11 feature set.
    Such is the the power of open source.

  • Ofek Shilon commented  ·   ·  Flag as inappropriate

    Knowing the amount of effort MS pours into backward compatibility (and the amount of heat they take when old programs break) I suspect the reason for preferring workarounds is not 'inability to implement ...', but rather reluctance to break existing code. Personally I respect this consideration.

  • David Ikeda commented  ·   ·  Flag as inappropriate

    While I'd love to have these features properly implemented, I think it's bad for us to make assumptions about Microsoft's attitude towards these features. You may be correct, but the attitude might very well alternatively be that they are providing workarounds simply to try to make up for their inability to implement these features in a more timely way (not necessarily seeing the workarounds as anything but a temporary solution).

Feedback and Knowledge Base