From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-05-04 22:44:40
On Sunday, May 4, 2003, at 21:32 America/Denver, Justin M. Lewis wrote:
> I think there is. It's no cost to distinguish. in_out tells you that
> better have the data initialized before passing it.
Isn't that what constructors are for?
> out lets you know that
> there's no need to initialize the data before passing it to the
> function. I
> guess the only issue here would be, does it cause a long term
> If at some point you decide that you want your out param to be in_out.
> Of course, if that's the case, you're probably doing a major
> rewrite of
> anything using your function anyway to make sure they're properly
> initialized. And, on the plus side, when you change it, you'll get
> errors everywhere you didn't fix the call.
> If you change an in_out to an out only param.
> This is probably a rare occurrence. It may not require a major
> But, again, you'll get compiler errors at every call you didn't go
> fix, so,
> whoever makes the change will have to go check every call.
> The compiler errors could be considered a good or bad thing. On the
> hand you have to check every call, on the other hand, it's a nuisance
> change something that may not need changing.
> ----- Original Message -----
> From: "Gregory Colvin" <gregory.colvin_at_[hidden]>
> To: "Boost mailing list" <boost_at_[hidden]>
> Sent: Sunday, May 04, 2003 7:48 PM
> Subject: Re: [boost] Re: in/out parameters, codingstylesandmaintenance
>> On Sunday, May 4, 2003, at 20:29 America/Denver, Noel Yap wrote:
>>>> From what I understand, then:
>>> - you want to find where variables are modified
>>> - you propose having in_out<> for in/out parameters
>>> - you propose having out<> for out parameters but don't propose
>>> preventing using it for in/out parameters
>> So is there any point to distinguishing out and in_out ?
>>> - you may want in<> for in parameters
>> Why is in<> any better than const& ?
>> Unsubscribe & other changes:
> 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