Everyone is ignoring the possibility of objects that can't be copied in this, too. Some objects intentionally hide their operator =, making returning it from a function impossible.
And, I think a lot of people are missing a big part of the point here. You can enforce the use of making it explicit at the point of invocation that the param is changing. The compiler will give an error if a c_out or c_in_out object isn't passed. You can't enforce a naming convention or commenting at the point of invocation, at least not everywhere, like where I work. So, by writing a function using these objects, it's a guarantee that anyone who uses my functions has to make it explicit what the effect of calling my functions is. ----- Original Message ----- From: "Noel Yap" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Thursday, April 24, 2003 4:13 AM Subject: Re: [boost] Re: class proposal > "Justin M. Lewis" wrote: > > > > in/out seems to be used fairly commonly in COM. I'm not sure I have any > > great examples off the top of my head, but I know they're commonly used. > > I'm not a COM person, but I believe it's written in C. If so, then you > are correct that in/out parameters are more needed since noone would > want to create a struct for each multiple return type. > > OTOH, C++ has templates to deal with this situation (ie boost::tuple<>) > so, qualifying my previous statement, in C++ I still see no need for > in/out parameters. > > > And using pointers is part of what we're trying to avoid here. Like I said, > > I avoid using pointers whenever possible at this point. > > I'm a little confused. Either you pass in the entire object or you pass > in a pointer (even if it's wrapped in another class). How is this new > class supposed to be implemented? > > > And, again, the real intent here is to insure clarity at the point of > > invocation. In my case I'm looking at 100's of thousands of lines of code, > > written over the past 8 years. It's tiresome trying to chase down where > > values COULD have changed. In this setup you KNOW exactly what calls are > > changing parameter values, and it's enforced. As long as the library calls > > use the c_out and c_in_out classes people using the library are forced to > > conform to the format. So, 8 years, and a few million lines of code later, > > no one will wonder what might cause a variable they're tracking to change > > values. > > I think if parameters are used for in parameters only and return values > are used for out parameters only, the same thing is achieved. For > example, > > inOutValue = square( inOutValue ); > > vs (using an extension for generality): > > square( c_in_out< typeof( inOutValue ) >( inOutValue ) ); > > Noel > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost