Re: [boost] Re: Re: class proposal

2003-04-24 Thread Terje Slettebø
From: Justin M. Lewis [EMAIL PROTECTED] As for a function returning a single param, I agree, normally you'd just return it, UNLESS it's some big structure you don't want being copied all over the place, then passing it by reference to a function makes more sense. The compiler may elide such

Re: [boost] Re: Re: class proposal

2003-04-24 Thread Terje Slettebø
Just to add some to my previous posting. Also, from a maintenance POV, having variables that doesn't change throughout a function (or program), tends to make it easier to understand. Having functions which change their arguments goes rather against that. One exception is input stream operators,

Re: [boost] Re: Re: class proposal

2003-04-24 Thread Noel Yap
Terje Slettebø wrote: The part about RVO was really concerned with the out() scenario, not in_out(). I'm not sure if passing a smart pointer buys you very much. In this case, the smart pointer is const but the pointee is not, so the const in the signature is really just masking what is going

[boost] Re: Re: class proposal

2003-04-23 Thread Bo Persson
Justin M. Lewis [EMAIL PROTECTED] skrev i meddelandet news:[EMAIL PROTECTED] Not entirely, passing a pointer doesn't tell you that the parameter will change, it just tells you that it might, it still leaves you in the position of having to track down the function and check it. But outside of

RE: [boost] Re: Re: class proposal

2003-04-23 Thread Justin M. Lewis
. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bo Persson Sent: Wednesday, April 23, 2003 11:32 AM To: [EMAIL PROTECTED] Subject: [boost] Re: Re: class proposal Justin M. Lewis [EMAIL PROTECTED] skrev i meddelandet news:[EMAIL PROTECTED] Not entirely, passing