However, if they let that one out of the headers, it would break legacy code, so I fail to see why they should let it outside.
Even if there was a legitimate reason to do it, on today's compilers, they can fix that mistake now. It's bad enough that the Windows API is C. Let's now screw up users C/C++ applications.
Originally Posted by Adak
No, it doesn't break anything. Yield is no longer available in new code-format. If you compile with a new Windows.h, then you get the new Yield. The actual Yield function only works in 16-bit .EXE's, so it would be clearly b0rken to expect a 32-bit app to run on a 16-bit system. So nothing is broken. It's just a way to remove a function that used to exist. It helps people porting old 16-bit apps to Windows 32-bit mode [not that it's likely to occur very often these days].
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Apart from the minor point that static inline functions are not supported in older versions of C, declaring a function as static inline can still introduce name clashes.
In the real world, companies like Microsoft come under more pressure to maintain backward compatibility (eg keep old code in header files that will work with old code) than they do from people who insist they must use the latest and greatest language features.
Corporate or government customers of companies like Microsoft often stick with older versions of compilers, etc that work and only upgrade if their are compelling business reasons to upgrade (the enjoyment of programmers being able to use modern language constructs is rarely a compelling business argument, and good programmers are productive whether they are allowed to use modern code constructs or not). The larger customers then tend to insist that any newer compilers maintain support of their old code without modification (as the cost of modernising old code is significant, and offers relatively few business benefits). Those customers give significant push-back if compatibility with old compilers is lost.
Large business clients tend to carry more weight than individuals, meaning a disincentive to lose backward compatibility. Business wise, it also makes sense for Microsoft to maintain one version that works rather than multiple versions that might break sometimes. In practice, that means headers like <windows.h> support the lowest common denominator -- vanilla C code, few if any C++ extensions, extensions that are common to all Microsoft compilers, use of macros, etc.
Does it mean that Microsoft attaches less priority to the programmers who want to use all the latest features? Sure. Those programmers tend to be a minority, and don't have the economic clout -- and Microsoft is not in business to provide services unless they profit from it. The pragmatic approach is to work within limitations (eg if you use <windows.h> pick names to avoid clashes) rather than insisting on large vendor like Microsoft supporting features (eg new pragmas) that benefit a minority. Unless, of course, you're willing to PAY Microsoft enough to make it worthwhile to support your features.
