From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-01 22:21:38
It doesn't need to be used everywhere in every project. The point is, if
you're starting something new, and you can be fairly sure that it's going to
be used for years to come, you can start a project with it. I'm not
suggesting that you use it IN the boost libraries even. I just see it as a
useful utility for anyone who would like to use it to keep their own code
----- Original Message -----
From: "Joel de Guzman" <djowel_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Thursday, May 01, 2003 7:14 PM
Subject: Re: [boost] in/out parameters, codingstylesandmaintenance
> Augustus Saunders wrote:
> > Whether or not somebody else actually uses the tool is not exactly
> > our problem. We can make sure that Boost libraries themselves use
> > this idiom anyplace that in/out parameters are called for (aside from
> > previously mentioned idiomatic usage in some operators) and guaruntee
> > correct, consistent use. Conceivably, this idiom could be useful
> > only for our own use, not even as a facitlity that we offer to
> > library users. But then again, there seems no reason to withhold it
> > if we use it internally. People will benefit to whatever extent they
> > use it, which is fine by me. My question, then:
> > Is it easy enough?
> No. If you force boost writers to retrofit all of their code, that would
> mean hundreds of thousands, if not, millions of lines of code. I'd
> rather spend my time on something more productive.
> > Does it work as advertised?
> > Like another poster pointed out, these probably require some actual
> > usage to answer.
> Chicken and egg, AFAICS.
> > But I don't think that a lack of global usage
> > guaruntees hinders the potential usefulness of the idea.
> Why? If it's not applied globally, it would be like installing some
> alarm system only in some places in your house. How useful is that?
> There would still be uncertainty.
> Joel de Guzman
> joel at boost-consulting.com
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk