Re: passing function object pointer to for_each argument
On 28 Sep., 18:59, Pete Becker <p...@versatilecoding.com> wrote:
On 2007-09-27 23:53:09 -0400, Abhishek Padmanabh
< abhishek.padman...@gmail.com> said:
On 27 Sep, 21:50, Daniel Kr?gler <daniel.krueg...@googlemail.com>
wrote:
Your problem is "slicing" and it occurs, because all
algorithms expecting a function do take these by
value (There is only one exception: random_shuffle, because
the random number generator usually contains state).
Why doesn't the standard mandate a pass-by-reference semantics? Pass
by reference should have had avoided this problem to begin with rather
than using the solution got by applying a wrapper containing the
functor pointer member. This would have been fine even with function
pointers. It also fixes the well-known stateful functor problem with
remove_if. Would there be any problem if it were adopted instead of
pass-by-value parameter for the algorithms interface? Or is it too
late to change the interface? Or does does this change even break any
existing code for that matter?
For some reasons, which I don't understand, I have not seen
this reply of Abhishek Padmanabh to my posting. Nevertheless,
since Pete Becker has brought this connection back to me,
I will also give my personal two (euro) cents here, v.i.
It's not as simple a change as it appears.
class Functor {};
Functor generate();
void f(Functor);
f(generate()); // pass temporary by value
void revised_f(Functor&);
revised_f(generate()); // error: attempting to bind temporary to
non-const reference
To get rid of this error, you could add another overload:
void f(const Functor&);
revised_f(generate()); // OK: binds temporary to const reference
but now you're right back were you started, with a non-modifiable functor.
Rightly argued, but I think there are some more words to
say here.
First, you could ask the following: "I heart that rvalue-
references will be part of C++0x - Does that mean, that we
should change the current algorithm signatures that they
should take functor arguments per rvalue?"
Indeed this approach would solve the above described
problem, because you could even provide rvalue
functors that are mutable:
void f(Functor&&);
f(generate()); // OK, takes by reference, but allows
// modification, because the argument will be moved!
Although this approach seems not to have any disadvantages
on a first view, there is still an argument that supports
"by-value" function arguments, namely the fact that these
allow better code optimizations. If the compiler "sees"
a value instead of a reference, it can "cut" the history
of that object (because a new one is there). This cannot
be done (in general), if there as a reference argument
even if that this is a const reference, because the constness
only restricts the function internal to modify it,
not the external side. Additionally, the internal code
can use a const_cast and modify the argument - whether
this is U.B. or not can *not* be decided from the
internal view of the function (because this depends on
the fact whether the actual argument was immutable or not).
For some better explanation I recommend to read the chapter
"Direct, Indirect, and Inline Calls" of the book "C++
Templates" by Vandevoorde & Josuttis.
Greetings from Bremen,
Daniel
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]