DM> Speaking of Boost.threads being part of C++0x, I agree
DM> whole-heartedly [...] that: since there is not yet any C++ binding
DM> for the POSIX.1 series (but there is for C, Ada, and Fortran), it
DM> would be a tragically missed opportunity for C++0x to standardize
DM> its own reinvented interface which does not provide [...] a
DM> C++ binding for POSIX.

The general consensus amongst people knowledgeable in such things,
whenever I have been present at such discussions, is that (a) the proper
place for C++ language bindings to the POSIX Threads API is the POSIX
Standard(s); and (b) given the significant differences in threading
models across operating systems, it is foolish, and does a great
disservice to applications programmers, to attempt to produce a single
API that maps on to them all.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jonathan de Boyne Pollard wrote:
>
> DM> Speaking of Boost.threads being part of C++0x, I agree
> DM> whole-heartedly [...] that: since there is not yet any C++ binding
> DM> for the POSIX.1 series (but there is for C, Ada, and Fortran), it
> DM> would be a tragically missed opportunity for C++0x to standardize
> DM> its own reinvented interface which does not provide [...] a
> DM> C++ binding for POSIX.
>
> The general consensus amongst people knowledgeable in such things,
> whenever I have been present at such discussions, is that (a) the proper
> place for C++ language bindings to the POSIX Threads API is the POSIX
> Standard(s);

Nah, the proper place for OS [threads including] C++ language
bindings is the {optional} C/C++ language bindings section(s)
in the *consolidated* C/C++/POSIX.1 *one single* 'right java'
standard. ;-)

> and (b) given the significant differences in threading
> models across operating systems, it is foolish, and does a great
> disservice to applications programmers,

Yeah... and ADA concurrency, Java/RTJ[1], Java/JSR-166[2], etc.
is just 'one example' of such "it is foolish, and does a great
disservice to applications programmers" thing, indeed. ;-) ;-)

> to attempt to produce a single API that maps on to them all.

Uhmm, I use fopen/fwrite to perform VSAM/PDS/HFS/etc. I/O...
what's wrong with such "single API that maps on to them all"?

regards,
alexander.

[1] http://www.rtj.org
[2] http://gee.cs.oswego.edu/dl/concurrency-interest/aims.html

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]