Re: Boost.threads standardization wishlist

From: scleary_at_[hidden]
Date: 2002-01-24 20:33:09

> -----Original Message-----
> From: Beman Dawes [mailto:bdawes_at_[hidden]]
> 
> At 02:01 PM 1/24/2002, bill_kempf wrote:
> 
>  >> but what about, for example,
>  >> programmers working in an embedded environment in which there is no
>  >> concept of threads/processes?
>  >
>  >There will be no requirement for them to support threads.  This is
>  >obviously true in Boost.Threads, and my understanding is that this is
>  >the thinking of the Committee members as well.
> 
> Yes.  The committee is working on a type 2 Technical Report.  Such TR's
are 
> non-normative.  That means a conforming implementation will not be
required 
> to provide anything in the TR.

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.

        -Steve