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
]