Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-07 08:26:58


----- Original Message -----
From: "Moore, Paul" <paul.moore_at_[hidden]>
> From: Beman Dawes <bdawes_at_[hidden]>
> > The following Boost libraries are already on the committee's
> > proposal list:
> >
> > 1) Header <cstdint>. (Tabled pending more comprehensive
> > proposal from Bill Plauger.)
> > 2) Type Traits.
> > 3) Regular Expressions.
> > 4) Smart Pointers.
> > 5) Random Numbers.
> > 6) Rational Numbers.
> > 7) Threads.
>
> This raises a question. As the author of the rational number library,
I
> didn't particularly do anything, or get involved, regarding the
inclusion of
> the library in this list. Don't get me wrong - I don't have a
particular
> issue with this, inasmuch as I don't see that there's anything much I
can
> contribute that others aren't able to handle better on my behalf. But
I
> don't recall any particular feedback on the library - certainly
nothing
> direct to me (I may have missed something in the list, as traffic
these days
> is far too high for me to get through everything). Does this imply
that
> there was no comment?

There was some discussion of whether a rational number library was
needed or appropriate for the next standard. Mostly, as I remember it,
Bill Plaugher said something like "it's not particularly convincing for
me", and some other people gave a bunch of reasons why it was important,
and Bill said (roughly) "I'm still not convinced, but I guess I
shouldn't object: the more bigger the standard library, the more
business for Dinkumware..."

> Or that the committee accepted the library as it
> stands with wholehearted enthusiasm :-)? Or simply that other things
took
> precedence, and they'll get to it in time?

We didn't look at the details of any of the libs, except possibly
threads a little bit.
>
> I do have some fairly strong views on the issue of keeping the library
> simple, for example. If the committee feels that some form of baroque
> template/specialisation/policy/traits mechanism is appropriate (to
allow
> user-level tuning of overflow behaviour vs efficiency, for example) do
I
> have any voice (beyond that of any random C++ user) to say "heck, no,
that's
> not what I intended"?

You can say that, and especially if you show up at a meeting your voice
will carry some weight, but I think the committee is free to change
things however it wants.

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk