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: 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: Re: class proposal
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 on. You're right. I see your point. At first I thought that if there were an easy way to convert smart_ptr T to smart_ptr T const there'd be no problem. But then I realized this would bring about the expensive copy again. IMHO, the solution to this dilemna is to use the de facto standard way of using references like you said earlier: void f( T value_may_change_, T const value_may_not_change_ ); 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:
I diagree with this. The code I've written using this looks more like
void add_char( in_outstd::string 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: 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
[boost] once_flag
Just wondering, looking at boost/thread/once.hpp, I see that once_flag is typedef'd to long, why not bool or char to take up less memory? Thanks, 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
[boost] newsgroup
The news group advertised on the site, news.gmane.org/gmane.comp.lib.boost.devel, gives no response. Has it moved? Thanks, 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
