Re: [boost] Re: class proposal
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
Re: [boost] Re: class proposal
"Justin M. Lewis" wrote: > > I diagree with this. The code I've written using this looks more like > > void add_char( in_out str, char ch) > { > std::string &s = str; > s += ch; > } I think you're assuming everyone will code the way you want. If you're going to force everyone to code this way, why not just have them code like: void add_char( std::string& str_, char ch_ ) { str += ch; } int len( std::string const& str ) { return str.length(); } What is the added value of the proposed class? It's not that it forces people to change the value if it's used: int len( in_out< std::string > str ) { return static_cast< std::string& >( str ).length(); } Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: class proposal
"Justin M. Lewis" wrote: > 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. I didn't really forget references. IMHO, references are pointers that are implicitly dereferenced. At the machine level, they are typically treated the same (eg address is passed by value). > 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. My reply to this was to use smart pointers. But as Terje Slettebø pointed out (but I got distracted by work before sending out my reply), smart pointers don't resolve the problem that the object may still change from underneath. I still think there's no need for the proposed wrapper class since: void f( T& value_may_change_, T const& value_may_not_change_ ); is still an acceptible alternative. IOW, if users stick to using T& only to indicate values that may change, and T const& to indicate values that may not change, the wrapper class has no added value (forgive the unintended pun). Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: class proposal
I diagree with this. The code I've written using this looks more like void add_char( in_out str, char ch) { std::string &s = str; s += ch; } - Original Message - From: "John Torjo" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Thursday, April 24, 2003 5:20 AM Subject: Re: [boost] Re: class proposal > > > void f( in_out< int > is_not_changed_ ) > > { > > // use is_not_changed_, but don't change it > > } > > I think there would be a much bigger problem (code inside the function would > change). > > Just consider > > void add_char( std::string & str, char ch) > { str += ch; } > > Now, if we change it so be in_out, we'll have to use a .ref()-like function. > > > void add_char( in_out str, char ch) > { str.ref() += ch; } > > Of course, this is a simple example, but it illustrates the point. > The code would become obfuscated. > > Frankly, I donot like it. > > Best, > John > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: class proposal
- 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
Re: [boost] Re: class proposal
> void f( in_out< int > is_not_changed_ ) > { > // use is_not_changed_, but don't change it > } I think there would be a much bigger problem (code inside the function would change). Just consider void add_char( std::string & str, char ch) { str += ch; } Now, if we change it so be in_out, we'll have to use a .ref()-like function. void add_char( in_out str, char ch) { str.ref() += ch; } Of course, this is a simple example, but it illustrates the point. The code would become obfuscated. Frankly, I donot like it. Best, John ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: class proposal
"Justin M. Lewis" wrote: > > I agree. I probably wouldn't have cared for this myself, had I never seen > the code I'm working on now. I mean, normally I work pretty independently. > But, now I'm stuck with the job of maintaining code that's been around > forever, has been ported several times to a couple different projects. In > places you can see how the code evolved over time. But, the point is, it's > becoming a mess. And, we're at a point where we're almost starting > everything again, but this time from scratch. Knowing that the code will > probably live for years, and be ported several times, and be maintained by > many different people over its life, it seems best to me to start a project > like that off with clarity being the #1 priority. And, at least in my > experience, people seem to think that functions that pass by reference > changing the values of params is a problem, it's hard to track. But, most > C++ people I know prefer to avoid pointer use. So, that really only leaves > the one option that makes the intent explicit and clear, every time. > > So, I really can't give a long term analysis of how well this method works, > if it becomes a hassle to maintain it, or not. But, as it is, it seems more > clear to me than anything else. At the cost of 3 or 6 letters at the > invocation point, you can make the operation of the function clear. > > func(out(x)); > > It seems pretty simple and straight forward to me. I believe all that will be accomplished is that these objects will become ubiquitous in the system just as references are. For example, code like the following will start to pop up: void f( in_out< int > is_not_changed_ ) { // use is_not_changed_, but don't change it } IMHO, why not just state from the start to ban in/out parameters? In its place, use parameters for "in" and return for "out". An in/out can done via a smart pointer. Noel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
Re: [boost] Re: class proposal
I agree. I probably wouldn't have cared for this myself, had I never seen the code I'm working on now. I mean, normally I work pretty independently. But, now I'm stuck with the job of maintaining code that's been around forever, has been ported several times to a couple different projects. In places you can see how the code evolved over time. But, the point is, it's becoming a mess. And, we're at a point where we're almost starting everything again, but this time from scratch. Knowing that the code will probably live for years, and be ported several times, and be maintained by many different people over its life, it seems best to me to start a project like that off with clarity being the #1 priority. And, at least in my experience, people seem to think that functions that pass by reference changing the values of params is a problem, it's hard to track. But, most C++ people I know prefer to avoid pointer use. So, that really only leaves the one option that makes the intent explicit and clear, every time. So, I really can't give a long term analysis of how well this method works, if it becomes a hassle to maintain it, or not. But, as it is, it seems more clear to me than anything else. At the cost of 3 or 6 letters at the invocation point, you can make the operation of the function clear. func(out(x)); It seems pretty simple and straight forward to me. Justin - Original Message - From: "Alisdair Meredith" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 23, 2003 7:01 PM Subject: [boost] Re: class proposal > > "Justin M. Lewis" wrote: > > > My idea was, if you make a simple template class, originally I called > > it CRetVal, you could force people to specify at the time the function > > is called what's going on. I made a helper template function retval > > that would create and return a CRetVal object of the desired type to > > save from needing to use template notation in line all over the > > place. So, the above would become something more like. > > > void func(CRetVal x){x = 1977;}; > > Interesting idea. I think I like it, similar to the way I like the idea > of an unmanaged_ptr<> template to indicate deliberate raw pointer use > clearly. > > Unfortunately, I think it is a hard sell, persuading people to type many > more characters to do something they have been familiar with using much > leaner syntax for years. If clarity matters it is usually indicated by > clear function/parameter naming, handily placed comments etc. so various > strategies for coping with the problem are out there. > > Persuading people that the increased clarity of intent for the single > parameter is worth the extra code-obfuscation of the call as a whole (as > any additional wrapper-syntax tends to obfuscate) may be a hard sell. > On the basis that nothing teaches like experience I'd certainly be > interested in giving it a go here though > > -- > AlisdairM > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: class proposal
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. 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. 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. - Original Message - From: "Noel Yap" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Wednesday, April 23, 2003 6:32 PM Subject: Re: [boost] Re: class proposal > "Justin M. Lewis" wrote: > > > > Yes, it is better. > > > > The first example has the problem of, you still have to go look up the > > function to see if it's actually changing anything, or if it's taking the > > param in, reading teh value, then modifying based on what was read. > > Then how about: > > boost::tuple< boost::shared_ptr< LargeObject > > result = f( > largeObjectSharedPtr ); > > > The second example has the problem of copying a potentially large object, > > and it doesn't allow for in/out params. > > I'm still not convinced that in/out parameters are necessary. > > Noel > -- > NOTICE: If received in error, please destroy and notify sender. Sender > does not waive confidentiality or privilege, and use is prohibited. > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: class proposal
"Justin M. Lewis" wrote: > > Yes, it is better. > > The first example has the problem of, you still have to go look up the > function to see if it's actually changing anything, or if it's taking the > param in, reading teh value, then modifying based on what was read. Then how about: boost::tuple< boost::shared_ptr< LargeObject > > result = f( largeObjectSharedPtr ); > The second example has the problem of copying a potentially large object, > and it doesn't allow for in/out params. I'm still not convinced that in/out parameters are necessary. Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: class proposal
Yes, it is better. The first example has the problem of, you still have to go look up the function to see if it's actually changing anything, or if it's taking the param in, reading teh value, then modifying based on what was read. The second example has the problem of copying a potentially large object, and it doesn't allow for in/out params. - Original Message - From: "Gregory Colvin" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Wednesday, April 23, 2003 5:34 PM Subject: Re: [boost] Re: class proposal > On Wednesday, Apr 23, 2003, at 16:07 America/Denver, Justin M. Lewis > wrote: > > Sorry if the explanation is a bit confusing. The whole idea here is to > > make it explicit at the function invocation that a parameter being > > passed will be used to return a value. > > > > A good example of where this would be useful is with a function call > > that takes some params, and returns several different things in > > different params, and still has an explicit return for an error code. > > At the invocation point it would be impossible to tell what's going on. > > > > int chk; > > chk = GetSomething(p1, p2, p3, p4, p5); > > > > where the actual declaration of GetSomething is like > > > > int GetSomething(int &ret1, int &ret2, int v1, int v2, int v3); > > > > It's impossible to tell at the invocation which params are returning, > > and which are being used to calculate the return. At the invocation it > > looks like chk might be what you're trying to get. > > > > With classes like I'm suggesting it would be obvious, the declaration > > would be: > > int GetSomething(c_out ret1, c_out &ret2, int v1, int v2, int > > v3); > > > > And at the invocation now, it has to be explicit that those first 2 > > params are out params. > > > > chk = GetSomething(out(p1), out(p2), p3, p4, p5); > > > > It REQUIRES you to use the out helper function at the invocation, so > > anyone reading the code later can see, without checking the > > implementation of GetSomething, that those 2 params are being set, and > > the last ones are not. > > Is this really that much better than > > chk = GetSomething(&p1, &p2, p3, p4, p5); > > or > > GotSomething ret = GetSomething(p3,p4,p5); > > ? > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: class proposal
Gregory Colvin wrote: > Is this really that much better than > > chk = GetSomething(&p1, &p2, p3, p4, p5); > > or > > GotSomething ret = GetSomething(p3,p4,p5); Or even: boost::tuple< int, int, bool > result = GetSomething( p1, p4, p5 ); Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: class proposal
On Wednesday, Apr 23, 2003, at 16:07 America/Denver, Justin M. Lewis wrote: Sorry if the explanation is a bit confusing. The whole idea here is to make it explicit at the function invocation that a parameter being passed will be used to return a value. A good example of where this would be useful is with a function call that takes some params, and returns several different things in different params, and still has an explicit return for an error code. At the invocation point it would be impossible to tell what's going on. int chk; chk = GetSomething(p1, p2, p3, p4, p5); where the actual declaration of GetSomething is like int GetSomething(int &ret1, int &ret2, int v1, int v2, int v3); It's impossible to tell at the invocation which params are returning, and which are being used to calculate the return. At the invocation it looks like chk might be what you're trying to get. With classes like I'm suggesting it would be obvious, the declaration would be: int GetSomething(c_out ret1, c_out &ret2, int v1, int v2, int v3); And at the invocation now, it has to be explicit that those first 2 params are out params. chk = GetSomething(out(p1), out(p2), p3, p4, p5); It REQUIRES you to use the out helper function at the invocation, so anyone reading the code later can see, without checking the implementation of GetSomething, that those 2 params are being set, and the last ones are not. Is this really that much better than chk = GetSomething(&p1, &p2, p3, p4, p5); or GotSomething ret = GetSomething(p3,p4,p5); ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: class proposal
Sorry if the explanation is a bit confusing. The whole idea here is to make it explicit at the function invocation that a parameter being passed will be used to return a value. A good example of where this would be useful is with a function call that takes some params, and returns several different things in different params, and still has an explicit return for an error code. At the invocation point it would be impossible to tell what's going on. int chk; chk = GetSomething(p1, p2, p3, p4, p5); where the actual declaration of GetSomething is like int GetSomething(int &ret1, int &ret2, int v1, int v2, int v3); It's impossible to tell at the invocation which params are returning, and which are being used to calculate the return. At the invocation it looks like chk might be what you're trying to get. With classes like I'm suggesting it would be obvious, the declaration would be: int GetSomething(c_out ret1, c_out &ret2, int v1, int v2, int v3); And at the invocation now, it has to be explicit that those first 2 params are out params. chk = GetSomething(out(p1), out(p2), p3, p4, p5); It REQUIRES you to use the out helper function at the invocation, so anyone reading the code later can see, without checking the implementation of GetSomething, that those 2 params are being set, and the last ones are not. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Terje Slettebø Sent: Wednesday, April 23, 2003 11:17 AM To: Boost mailing list Subject: Re: [boost] Re: class proposal >From: "Terje Slettebø" <[EMAIL PROTECTED]> > >From: "Justin M. Lewis" <[EMAIL PROTECTED]> > > > Well, I guess, based on all the code I've been reading at work it didn't > > seem so small, chasing down all kinds of functions across 100's of files > > to see why exactly values are changing mid function I'm looking at > > without warning. > > > > Anyway, this would allow for stronger enforcement of the rule that > > changing params should be marked somehow. As the programmer of a > > library people are using, I can force them to mark the params they're > > passing as out or in_out, so in 5 years when someone else comes along > > and has to debug it, it's all clear what's happening. > > Why not use T & if the function may change it, and const T & if it won't? After I sent it, I realised that the issue was marking it at the _caller's_ side, so then this doesn't apply. It was a little difficult to understand the proposal, as it mentioned c_in_out and c_out, while the code example uses CRetVal and the retval function. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: class proposal
On Wednesday, Apr 23, 2003, at 12:04 America/Denver, Terje Slettebø wrote: From: "Justin M. Lewis" <[EMAIL PROTECTED]> Well, I guess, based on all the code I've been reading at work it didn't seem so small, chasing down all kinds of functions across 100's of files to see why exactly values are changing mid function I'm looking at without warning. Anyway, this would allow for stronger enforcement of the rule that changing params should be marked somehow. As the programmer of a library people are using, I can force them to mark the params they're passing as out or in_out, so in 5 years when someone else comes along and has to debug it, it's all clear what's happening. Why not use T & if the function may change it, and const T & if it won't? Because looking at the call f(&x) I wonder what happens to x, whereas looking at the call f(x) I don't? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: class proposal
>From: "Terje Slettebø" <[EMAIL PROTECTED]> > >From: "Justin M. Lewis" <[EMAIL PROTECTED]> > > > Well, I guess, based on all the code I've been reading at work it didn't > > seem so small, chasing down all kinds of functions across 100's of files > > to see why exactly values are changing mid function I'm looking at > > without warning. > > > > Anyway, this would allow for stronger enforcement of the rule that > > changing params should be marked somehow. As the programmer of a > > library people are using, I can force them to mark the params they're > > passing as out or in_out, so in 5 years when someone else comes along > > and has to debug it, it's all clear what's happening. > > Why not use T & if the function may change it, and const T & if it won't? After I sent it, I realised that the issue was marking it at the _caller's_ side, so then this doesn't apply. It was a little difficult to understand the proposal, as it mentioned c_in_out and c_out, while the code example uses CRetVal and the retval function. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: class proposal
>From: "Justin M. Lewis" <[EMAIL PROTECTED]> > Well, I guess, based on all the code I've been reading at work it didn't > seem so small, chasing down all kinds of functions across 100's of files > to see why exactly values are changing mid function I'm looking at > without warning. > > Anyway, this would allow for stronger enforcement of the rule that > changing params should be marked somehow. As the programmer of a > library people are using, I can force them to mark the params they're > passing as out or in_out, so in 5 years when someone else comes along > and has to debug it, it's all clear what's happening. Why not use T & if the function may change it, and const T & if it won't? Simple and clear. No need to use pointers, to differentiate between it. An advantage with references is that you may pass by value, or const reference, and to the caller, it's called in the same way, so the pass by value or const reference may be an implementation detail. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: class proposal
Well, I guess, based on all the code I've been reading at work it didn't seem so small, chasing down all kinds of functions across 100's of files to see why exactly values are changing mid function I'm looking at without warning. Anyway, this would allow for stronger enforcement of the rule that changing params should be marked somehow. As the programmer of a library people are using, I can force them to mark the params they're passing as out or in_out, so in 5 years when someone else comes along and has to debug it, it's all clear what's happening. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vincent Finn Sent: Wednesday, April 23, 2003 10:12 AM To: [EMAIL PROTECTED] Subject: [boost] Re: class proposal Justin M. Lewis wrote: > 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 that, if > you're like me, at this point you prefer references to pointers, whenever > possible. I did use references everywhere but changed to pointers for the reason you are talking about I only use pointers if the argument might be changed that way the &varName means varName will be changed in the function if the arg won't be changed I pass const& The only reason for doing this is to make it obvious which are in parameters and which are out\inout using a class just seemed like over kill for something so small Oh well, it is all a matter of taste I suppose Vin ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: class proposal
That depends. At one point the out and in_out classes had assert checks in them. c_out would check to make sure that it was assigned some value inside the called function, for example. The other thing is, the idea here is to force people CALLING your function (func) to show the world what's going on by using the out or in_out function at the point func is called. You'd also want totally separate types that can't be implicitly cast from one to the other, since the point here is to make it clear at the point func is called what is happening to the parameters that are passed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gennadiy Rozental Sent: Wednesday, April 23, 2003 1:20 AM To: [EMAIL PROTECTED] Subject: [boost] Re: class proposal > void func(CRetVal x){x = 1977;}; Basically boost::ref could be used for the same purpose, isn't it? Just different name Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: class proposal
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 that, if you're like me, at this point you prefer references to pointers, whenever possible. - Original Message - From: "Vincent Finn" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 23, 2003 2:09 AM Subject: [boost] Re: class proposal > Justin M. Lewis wrote: > > I don't really know how this works. I know someone who's a big Boost > > fan, and he said he didn't know of anything like what I'm going to > > propose exists in Boost here. So, here it is. > > > > The problem I was having, we have references, that allows me to pass a > > paramter to a function, that function modifies the value passed in, at > > the point where that function is called, I cannot tell that the data is > > being modified. Basically, it leads to somewhat confusing code, > > especially in a case where you're looking at someone else's code trying > > to track down where a value gets set. > > > > void func(int &x){x = 1977;}; > > > > void blah() > > { > > int y=0; > > func(y); > > func2(y); > > printf("%d\n", y); > > } > > > > > > Something along those lines could become confusing, obviously in a much > > larger program. > > > > My idea was, if you make a simple template class, originally I called it > > CRetVal, you could force people to specify at the time the function is > > called what's going on. I made a helper template function retval that > > would create and return a CRetVal object of the desired type to save > > from needing to use template notation in line all over the place. So, > > the above would become something more like. > > > > void func(CRetVal x){x = 1977;}; > > > > void blah() > > { > > int y=0; > > func(retval(y)); > > func2(y); > > printf("%d\n", y); > > } > > could you not get the same effect by using > void func(int* px) {*px = 1977;} > > int y = 0; > func(&y); > func2(y); > > Vin > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost