Boost logo

Boost :

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?

Good point.

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, gregod at, cpdaniel at, john at