----- 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. > I think most COM objects are written in C++. I should have been more specific here, if you're looking at ActiveX objects, in/out params are used all over the place. Each function returns an HRESULT, iirc, any data you want returned has to be returned in a param. > > 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, it's not either pass in a whole object or pass in a pointer, you're forgetting references. This new class takes in a reference, and stores that. It doesn't do anything with pointers. > > 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 > And, again, returning an object isn't always desirable, you could be copying large objects for no reason. You may not call a copy constructor, but an = operator is being used. _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
