To be fair, had you read the docs up front, you wouldn't have been confused at all. :-)
Also, please recall that "inline" is a C++ thing (yes most compilers have an option to enable certain C++ extensions in C, but you made such a big deal about ANSI standards that it seems you aren't the sort of person who would condone using the non-ANSI extensions anyway). I could go on with several other reasons why it's not as bad as you make out, and even several reasons why it's actually beneficial. If you think on it a while (or read up on it) you can come up with some of the reasons yourself, so I'll leave that to you. "Loc" <[EMAIL PROTECTED]> wrote in message news:114187@palm-dev-forum... > > Why must Palm try to be unique? > > Been pulling my hair out for several hours over strange Metrowerks compile > errors. Been cursing Metrowerks then figured out the problem was Palm's > fault. It is such a beautiful platform that they decided to defy the C/C++ > world by having their own function name that are slightly off from ANSI. To > alleviate the C/C++ developers' frustration, they defined macros that maps > ANSI to their own functions. This really makes life easier when you are > free from the burden of naming your functions with silly names like close() > or open() since sys_socket.h defines macros that maps close() and open(). > These were macros instead of inline functions because that would be too ANSI > and developer friendly. What to do? Rename my functions? Well that would > break the code for those silly Windows and Unix developers who use the same > code and are burdened with such naming anachronisms. Guess it's time to > practice the art of ifdef'ing. Who needs standards, right? Thank you, Palm > for relieving me of these silly naming conventions. Thank you very much! > > > > > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
