On Sat, 2007-09-15 at 14:42 +0200, Sven Panne wrote:
On Saturday 15 September 2007 13:58, skaller wrote:
The RIGHT way to do this is rather messy .. but there is only one right way to do it. [...]
IMHO things are not that black or white: I think we have a tradeoff between almost 100% fool-proofness (which is basically the approach you describe) and the ability to do cross-compilation (use available headers and perhaps fail/guess if nothings sensible could be found). What is "right" has to be decided on a case-by-case basis.
Of course.
But of course you are totally right in one respect: OS-based tests when used in a context like our example are silly and should be replaced by feature-based tests (be it "Do we have
?" or "What is the result of compiling/running blah.c?").
I think the key point is that if you need say int32_t or intptr_t you must not use them, but instead use my_int_32_t or my_intptr_t size_t is required by ISO C89, C99 and C++ Standards so can be used directly. This is annoying, but if you use these in interfaces defining your own is necessary to avoid conflicts. In implementations there's more freedom .. but no point not using the 'my_' versions. In effect, this removes the 'optional' status of the symbols and creates an in-house de-facto standard you can rely on. Pity ISO didn't do that originally .. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net