Topic: reference correctness
Author: jpotter@falcon.lhup.edu (John E. Potter)
Date: 1997/04/09 Raw View
#include <algorithm>
class A {};
class B {};
A foo (B const& lhs, B const& rhs) { A a; /* ... */ return a; }
This looks like a very common function form.
ptr_fun(foo);
ERROR: passing `A (*)(const B &, const B &)'
as argument 1 of `ptr_fun(A (*)(B, B))'
Common sence tells me that this is a compiler bug. Either it can not
deduce the correct instantiation or it works, seems to make sence;
however, common sence has nothing to do with standardization. Is this
a bug or is it possible to correctly deduce an unusable instantiation?
pointer_to_binary_function<B const&, B const&, A> bar(foo);
OK, that problem has a workaround. Moving on:
bind1st(bar, B());
ERROR: cannot declare references to references
Of course, I should have expected this when I used a reference in the
above declaration.
struct Abinder {
Abinder (B const& l) : lr(l) { }
A operator() (B const& rr) { return foo(lr, rr); }
B const& lr;
};
That also has a workaround but the porblem could be a bug in the
standard. References are generally discouraged as template
parameters because most templates are not written with reference
correctness in mind. But what I really wanted to write was
bind1st(fun_ptr(foo), B())
which seems quite natural and does not show any obvious reference
template parameters. It seems that binder1st (and 2nd) could be
specified with reference correctness. Perhaps it was a oversight
or typo, or maybe there is something that I do not see. The
change would be to the two public members.
binder1st(const Operation& x, const Operation::first_argument_type& y);
result_type operator()(const argument_type& x) const;
become
binder1st(const Operation& x, Operation::first_argument_type y);
result_type operator()(argument_type x) const;
I suspect that the const& form was used naturally in these two functions
just as I did in foo. I left the const& on Operation; however, it could
likely also be removed. I do not see any problem with passing by value
in the cases which would currently work. The only problem that I can
see is that storing the bound item by reference could cause an aliasing
problem in some applications. Is this a simple fix of an oversight or
are there other things which I have not considered?
John
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]