From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-09-17 14:37:00
From: "Gennaro Prota" <gennaro_prota_at_[hidden]>
> On Tue, 17 Sep 2002 13:35:02 -0400, Beman Dawes <bdawes_at_[hidden]>
> >Now someone might say that such a modified interface proposal is no
> >existing practice. But the LWG takes a wider view, and expects some
> >as an interface is readied for final submission to them.
> But I think many people use boost also because there's the (not so)
> implicit idea that they will have less to modify in their code
> (compared to some home-rolled solution) when the components they need
> will be standardized. What you describe above means that this
> advantage is really nonexistent, no?
It's still true.
Scenario A: people use library X. Something gets standardized. Modifications
required if they want to migrate to standard components.
Scenario B: people use boost::Y. boost::Y gets standardized. Some
modifications required, but less than scenario A.
Or for a different perspective: imagine a hypothetical situation where
boost::Z's interface can be improved.
Case 1: boost release 1.NN contains a new version of boost::Z that later
Case 2: boost::Z stays as is, when it gets standardized, std::Z adopts the
Case 3: boost::Z is standardized as is, and we are stuck with an inferior
Which one would you prefer?
> Also, I haven't understood Mr. Abrahams idea about a boost release
> being "something available". I think we should not forget that when
> boost releases there will certainly be a lot of people that will start
> using the released code. If the goal is only to have the code
> available for the committee why not creating e.g. a "committee
> sandbox" instead of binding people with something released in a hurry
> and, above all, not (expressly) for their use?
This is out of context. 1.29.0 was supposed to go out a month ago. That's
the problem that is being discussed.
I see nothing wrong with the fact that the committee is part of Boost's
target audience, so to speak. There is no conflict of interest.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk