From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-05-01 10:52:12
At 10:58 AM 5/1/2003, David Abrahams wrote:
>Beman Dawes <bdawes_at_[hidden]> writes:
>> * What if the committee changes the namespace?
>> Hum... That could happen. Maybe we should use a macro to make it
>> to change.
>Isn't that what namespace aliases are for?
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.
* Should we include components not originating from Boost?
Yes, although that depends on developers willing to contribute
* 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. Details
need to be worked out.
* 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.
* 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.
* 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
want to continue as we don't want to compete against the standard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk