Boost logo

Boost :

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-04 22:32:14


I think there is. It's no cost to distinguish. in_out tells you that you
better have the data initialized before passing it. 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 maintenance
problem.

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 compiler
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 rewrite.
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 one
hand you have to check every call, on the other hand, it's a nuisance to
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:
http://lists.boost.org/mailman/listinfo.cgi/boost
>


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