Function name clash?

This is a discussion on Function name clash? within the C++ Programming forums, part of the General Programming Boards category; However, if they let that one out of the headers, it would break legacy code, so I fail to see ...

  1. #16
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,665
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #17
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    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.
    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.

  3. #18
    Registered User
    Join Date
    Jun 2005
    Posts
    6,339
    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.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Seg Fault in Compare Function
    By tytelizgal in forum C Programming
    Replies: 1
    Last Post: 10-25-2008, 03:06 PM
  2. Another syntax error
    By caldeira in forum C Programming
    Replies: 31
    Last Post: 09-05-2008, 01:01 AM
  3. In over my head
    By Shelnutt2 in forum C Programming
    Replies: 1
    Last Post: 07-08-2008, 06:54 PM
  4. Replies: 28
    Last Post: 07-16-2006, 11:35 PM
  5. const at the end of a sub routine?
    By Kleid-0 in forum C++ Programming
    Replies: 14
    Last Post: 10-23-2005, 06:44 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21