From: David Abrahams (dave_at_[hidden])
Date: 2003-05-02 08:23:12
Beman Dawes <bdawes_at_[hidden]> writes:
> What is your opinion on the other issues?
> * Should Boost implement the library TR?
> Yes, although each library developer needs to make sure that makes
> sense for their library, and they are willing to do the work.
I'm not sure. There's at least one TR library which isn't a boost
> * Should we include components not originating from Boost?
> Yes, although that depends on developers willing to contribute
What does this mean? Lots of boost libraries originated on someone's
machine at home.
> * Including the components originating from the C library?
> No, in general, because the compiler suppliers will usually
> supply those components. Where the lack of a C component is a
> hindrance, we might supply a Boost version as we have done for
> a few standard library headers.
> * Do TR components need a formal review?
> Some kind of review is needed to ensure quality, but the process
> should be simplified compared to a normal formal review.
Why? Presumably the specification will be even more rigorous than
what we have at Boost, since there will have been more eyes on it. I
think we ought to consider going the other way.
> * Should we track TR changes made by the committee?
> Yes. The rationale for providing a TR implementation is to (1)
> make the TR available for compilers not yet delivering their own
> version, and (2) providing a reality check on the committee's TR
> specifications. Both of those require a Boost implementation
> track committee changes.
If possible, yes.
> * Should our TR implementation permit extensions?
> No, unless they can be turned off.
> * What namespace should the Boost version go in?
> ("tr1" is "t", "r", followed by numeral one, and is the committee's
> tentative choice for a sub-namespace.)
> std::tr1 // well, this IS an implementation of the standard TR
> boost::tr1 // users can pick and choose, also more traditional
> * What header naming convention?
> ???? Note that users can pick and choose an implementation by header
> choice, even if we use namespace std::tr1.
Same as the standard, plus .hpp.
> * What happens when a compiler vendor starts to supply TR components?
> We might want to develop some guidelines for users, particularly if
> we don't use namespace std::tr1.
> It might be very useful to be able to run the Boost tests against
> vendor supplied TR implementations. That could help the industry
> achieve compliance faster, and would turn up differences in
> interpretation of the specification.
> * Should we continue to maintain the pre-TR Boost versions of the
> Decide this on a library by library basis???? Long term,
> probably don't want to continue as we don't want to compete
> against the standard itself.
We certainly have extensions we'll want to maintain.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk