tags:

views:

416

answers:

4

I have a simple class like this:

class A
{
public:
    void f(const int& n)
    {
     std::cout<<"A::f()" << n <<"\n";
    }
};

and I am trying to use it like this:

std::vector<A> vec;
A a;
vec.push_back(a);
std::for_each(vec.begin(), vec.end(), std::bind2nd(std::mem_fun_ref(&A::f), 9));

But when I compile the code I get the following error somewhere inside functional header file:

error C2529: '_Right' : reference to reference is illegal

If I remove the reference in the parameter f() it compiles fine. How do I resolve this? I don't want to remove the reference as in my real code the copying of the object is quite costly. Also, I am not using boost.

+1  A: 

I dont believe you can bind parameters to a method that takes references. (not in the STL, I think the boost versions may let you do it but I am not sure)

You will need to roll your own.

struct CallF
{
    CallF(int const& data): m_data(data)    {}
    void operator()(A& val) const
    {
        val.f(m_data);
    }
    int const& m_data;
};

Use like this:

    std::for_each(vec.begin(), vec.end(), CallF(9));
Martin York
A: 

Actually, the compilers error message tells the whole story:

error C2529: '_Right' : reference to reference is illegal

std:: binders take their arguments as references - you cant pass a reference to a reference.

No way.

RED SOFT ADAIR
+4  A: 

You can't do that easily, sorry. Just consider it one of those cases not covered by std::bind1st and std::bind2nd (kinda like 3-argument functions etc). Boost would help - boost::bind supports references transparently, and there's also boost::ref.

If your implementation supports TR1 - latest g++ versions and VC++2008 SP1 both do - then you can use std::tr1::bind, which is for the most part same as boost::bind, but standardized.

Pavel Minaev
"standardized" is a bit of an overstatement, I think. The technical report is at most a quasi-standard. Unfortunately, it doesn't say, how the header files can be included. G++ adopts the <tr1/soandso> style whereas in VC++ -- correct me if I'm wrong -- the headers are included without leading "tr1/".
sellibitze
Well, it's still a document designed by committee and reusable by implementors. Regarding header names - TR spec consistently refers to them as `<foo>`, so there's no ambiguity; if g++ _requires_ `<tr/foo>`, then it is not conformant - but are you sure that it is a requirement and not an option? In any case, `std::tr1::bind` is specified to not be in a new separate header, but as an addition to existing header `<functional>`.
Pavel Minaev
I don't share your interpretation and GNU obviously also doesn't. See 1.3/3-4. Let me quote paragraph 4: "It is recommended either that additional declarations in standard headers be protected with a macro that is not defined by default, or else that all extended headers, including both new headers and parallel versions of standard headers with nonstandard declarations, be placed in a _separate directory_ that is _not part of the default search path_.
sellibitze
"Default search path" does not imply that you cannot reference the headers as `<foo>` (in fact, it's a term that is not defined anywhere in ISO C++ spec). It only implies that you need additional compiler switches (or other analogous mechanism to opt-in) to have those headers accessible as `<foo>`. The idea is that a C++ implementation should provide TR1 functionality only when requested by some implementation-defined means. But it obviously can't mean that full header names are implementation defined - otherwise writing portable code using TR1 would be impossible.
Pavel Minaev
In any case, it is trivial to get TR1 headers accessible "normally" uunder g++ by adding the directory which contains them to its include path.
Pavel Minaev
+1  A: 

I've been bitten by the same problem. If you look into the C++ standard, you'll see that it's actually a "library defect". A conforming C++ implementation simply can't deal with reference parameters. mem_fun_ref returns an object of a class that has nested typedefs (

argument_type, first_argument_type, second_argument_type

) where references are not stripped away. bind1st and bind2nd are specified to have an operator() wich takes references as parameters. In case argument_type is a reference already this will fail to compile.

One solution might be to replace memfunref with your own template magic and strip away references for the nested argument_type typedefs.

sellibitze