I agree completely. It's nice to have a common/portable framework, but it is unrealistic to assume that the framework will be sufficient for all use cases. This is true going both directions though. I'll pick on files because they are easy<g>. There are FILE*, iostreams, int fd, etc.. There is a bidirectional relationship between FILE* and int (via fileno/fdopen), but no connection between those int's and whatever native type is used (ex: HANDLE in Windows). Visual C++ has undocumented methods to create a suitable int from a HANDLE, which allows one to pass any native flags or what-not when opening the HANDLE and still use the rest of the standard library. To be truly useful, a portability library must provide some means to connect to the native system and do so bidirectionally where possible. In my own code, I provide get_native() methods to get the native artifact and document the semantics as non-portable. I also provide a way to create classes given already created native "objects" (where appropriate). This kind of support differentiates libraries that have aesthetic appeal from those that work in the real world (IMHO). <digress>This has been a bone of contention I have with the C/C++ standard bodies. Given the computing environment today, there should at least be a Windows and *nix annex that describe non-portable, but yet standard bindings, much like CORBA does with languages. Any other environments that wanted to define their own annex should also do so. But, I've been around long enough to know the chances of this actually happening.. :( </digress> Don --- David Abrahams <dave@boost-consulting.com> wrote:

You have to understand, the Boost.Threads specification was designed to become a standard, and as such it didn't include anything nonportable. That said, there's no reason we shouldn't expose the low-level thread IDs and document them in a special section on platform specifics.

__________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs