|
Boost : |
From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2002-01-25 02:40:17
scleary_at_[hidden] wrote:
> Pardon my ignorance of the standardization process, but would the committee
> be open to a stricter requirement? What I am thinking of is something
> worded in a way that if the platform supports threads, then they must
> support the C++ thread API. That would guarantee that the API would be
> available whenever possible, but not place a burden on embedded systems.
>>From what I understand, this level of requirement can't be placed in a TR.
>
> If the committee is open to doing this for threads, it would be a good idea
> to have compile-time indications of the presence of the thread API. It
> might also be a good idea to do the same for other APIs or possibly language
> facilities (exceptions/RTTI). I'm not suggesting anything like POSIX, which
> in my opinion goes too far in splitting up portions of their standard into
> optional parts. I'm just saying we could allow that for platform
> limitations only.
Another option would be that you can ask the library what the maximum
amount of threads is that are allowed to be started. On platforms that
do not support threads, this function always returns 0.
This makes the limitation not a burden on the development (the program
always needs to be able to cope with failing to start another thread)
and the code does not need to full of #ifdef's to check if the interface
is indeed available.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk