Re: [boost] Re: Boost.threads standardization wishlist

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-25 16:25:03

At 08:33 PM 1/24/2002, scleary_at_[hidden] wrote:

 >> -----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?

Yes, but not in the Technical Report.  One point of the TR is to build 
experience.  Then when the next revision of the standard rolls around, 
committee members will have a much better handle on what should be 
required, and what shouldn't be.

 >  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.

C++ (and C too, IIRC) already has a concept (1.4) of "hosted" or 
"freestanding" implementations, where "freestanding" is defined as not 
having an operating system.  It is implementation defined what portions of 
the library they support.

 >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).

There has already been discussion of doing so, but details won't be worked 
out until there is a firmer idea of what is going into the TR.

--Beman