"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u4qjqq4is.fsf@boost-consulting.com... | Thorsten Ottosen <nesotto@cs.auc.dk> writes:
| > AFAICT, not more state than that already needed by the parameters | > of the function. | | Yes, it requires more state. The value passed to set_XXX has to be | stored somewhere.
but one can store a reference if that is beneficial.
| >> One major problem with state (aside from stylistic concerns which I | >> also consider valid) is: | >> | >> f(table = create_a_table(), name = "boxes") | >> | >> if create_a_table returns a vector, it can be passed by reference all | >> the way through to f's implementation. With | >> obj.set_table(create_a_table()), you have to store a copy of the | >> vector. | > | > why can't you store a reference? | | Because you'd be storing a reference to a temporary, which would have | evaporated by the time you get to actually initiate the call.
you must be confusing move-semantics with this situation, or I'm missing something.
You're missing something.
there should be no difference between storing a temporary implicitly or explicitly...it's still there and still takes up stack-space no matter what.
Yes, but your scheme requires copying that temporary into a new object, where it is stored again. The proposed library allows a reference to be bound to the temporary with no copying. And I seriously doubt there is a compiler in existence today that can elide that copy, because of the restrictions on where the object must be stored.
If the function does return a reference, then simply store that instead of copying the whole object.
Yes, but now you have to tell the user "don't call me with anything that returns a temporary, even though I'll compile it without complaint." f_er f; f.set_table(create_a_table()); // whoops, the table disappears f.f() // BOOM or whatever.
| > (which would loose the defaults and explicit-naming, a significant | > drawback) | | Not true. Bind would not loose the explicit naming or the defaults. | As for function<>, no alternative approach you can name would | preserve them, either.
if you have an object that wraps an algorithms somehow, you can just pass that object around by its name.
riiiiiiight.....
For example, you can pass the painter object around and change state explicitly by p.set_hue( ... ); So the mecanism that is used to document intend does not disappear as it otherwise would.
...but that's not holding it inside a boost::function<>. The whole point of function<> is type erasure, and with it goes the information about how to process named parameters. This doesn't seem like a very well-reasoned argument you're making.
| I didn't think that it was important for the library docs to discuss | alternative approaches. We have almost no discussion of alternative | approaches in the body of any of our libraries' documentation. Yes, | there are occasional rationales for specific design choices.
IMO, any boost library should be able to answer why it is the best library for the given task. Sometimes its easy to do so; sometimes its hard.
Oh, that's simple. There aren't any alternative libraries for this task "out there."
| > - possible performance drop? | | Any method that requires stateful storage will incur a greater | performance drop than building a struct of references.
not if you store big objects by reference. And that has been my point all along.
And my point all along is that you can do that but you need to tell users to be careful with temporaries in that case.
| > That is enough for me to start looking for alternatives which | > have the same benefits and a new set of drawbacks. I wouldn't | > conclude as you have done, that named parameters is the best | > solution. | | To what? | | Named parameters aren't as much a solution to anything as an | expressive programming idiom that has been used very successfully in | all kinds of languages and environments.
Self documenting code is a really fine goal; there are just other ways to do it. My no vote simple reflects that I don't the see the current library's benefit/problem ratio as big enough.
Fair enough. You're entitled to it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com