Re: [boost] Re: class proposal

2003-04-24 Thread Justin M. Lewis
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 us

Re: [boost] Re: class proposal

2003-04-24 Thread Noel Yap
"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

Re: [boost] Re: class proposal

2003-04-24 Thread Noel Yap
"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 im

Re: [boost] Re: class proposal

2003-04-24 Thread Justin M. Lewis
]> 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

Re: [boost] Re: class proposal

2003-04-24 Thread Justin M. Lewis
- 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 seem

Re: [boost] Re: class proposal

2003-04-24 Thread John Torjo
> 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_

Re: [boost] Re: class proposal

2003-04-24 Thread Noel Yap
"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

Re: [boost] Re: class proposal

2003-04-24 Thread Noel Yap
"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 need

Re: [boost] Re: class proposal

2003-04-23 Thread Justin M. Lewis
eredith" <[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, y

Re: [boost] Re: class proposal

2003-04-23 Thread Justin M. Lewis
acking 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: > >

[boost] Re: class proposal

2003-04-23 Thread Alisdair Meredith
> "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

Re: [boost] Re: class proposal

2003-04-23 Thread Noel Yap
"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::t

Re: [boost] Re: class proposal

2003-04-23 Thread Justin M. Lewis
otentially 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

Re: [boost] Re: class proposal

2003-04-23 Thread Noel Yap
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

Re: [boost] Re: class proposal

2003-04-23 Thread Gregory Colvin
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

RE: [boost] Re: class proposal

2003-04-23 Thread Justin M. Lewis
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

Re: [boost] Re: class proposal

2003-04-23 Thread Gregory Colvin
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

Re: [boost] Re: class proposal

2003-04-23 Thread Terje Slettebø
>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 func

Re: [boost] Re: class proposal

2003-04-23 Thread Terje Slettebø
>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, thi

RE: [boost] Re: class proposal

2003-04-23 Thread Justin M. Lewis
in -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

RE: [boost] Re: class proposal

2003-04-23 Thread Justin M. Lewis
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

[boost] Re: class proposal

2003-04-23 Thread Vincent Finn
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 reference

Re: [boost] Re: class proposal

2003-04-23 Thread Justin M. Lewis
o 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