On 10/10/16 18:28, Billy O'Neal (VC LIBS) wrote:
So this library/compiler decoupling has the consequence of delaying bug fixes users are waiting for. Shouldn't users be allowed to make the "break ABI" choice for themselves? I.E. supply both MSVCP140.dll and MSVCP150.dll with 140 the default initially, then 150 further down the road, then eventually no longer supply 140.
Feedback from customers was that breaking bincompat every year was too rapid. We don't want to get into maintaining a bunch of separate forks. We are still maintaining, providing bugfixes for, and adding new features (like <variant>, <any>,
) to 140; 150 is not yet ready to ship.
Why adding export symbols for char16_t and char32_t is considered a breakage? You could just make those symbols point to the unsigned short and unsigned int API implementation that you already provide and recommend using in the MS Connect tickets. IMHO, this sort of bugs should have been fixed even before VC14 RTM, let alone the later updates.