Getting back to what was origonally said - if one platform implements something that another platform doesn't, how can a cross platform library not re-invent the the wheel for that crummy platform?
That's not reinventing the wheel for that "crummy platform," it's implementing it. What's reinvention is ignoring the existing implementation on the other platforms.
I do agree mostly, except that Boost is meant to be cross-platform, which means shipping the Boost source code with the platform abstraction layer.
Sure.
And shipping the resultant library to conatin that code as well - think win32 running on win98 vs win32 running on win2k.
The extra code would be part of the sources, sure, but it only needs to be compiled into the executable when needed.
There would need to be runtime detection of the available functionaly (for only some functions - but the problem does exist).
Runtime? Surely we can get the required information as to the available feature set from a compile-time version number, can't we? In the worst case, I could imagine a discovery tool run by Boost Build that computes the available feature set and generates a configuration header that the rest of the library relies upon.
Not on win32 - actually you are correct that you _could do that_. However, your executable would then not be portable between various flavours of win32 - which in itself is no different from most Unix's - but is not really want you want to do for win32. Mathew