From: Don G (dongryphon_at_[hidden])
Date: 2005-03-12 14:30:43
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>
--- David Abrahams <dave_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk