By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,804 Members | 1,627 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,804 IT Pros & Developers. It's quick & easy.

Qualifiers lost compiling STL code

P: n/a
Given the following code:

#include <vector>
#include <algorithm>
#include <functional>

class Value
{
public:
explicit Value(int value) : m_value(value) {}
void ChangeTo(int value) { m_value = value; }

private:
int m_value;
};

int main()
{
std::vector<Value> values;
values.insert(values.end(), 5, Value(6));

std::for_each(values.begin(), values.end(),
std::bind2nd(std::mem_fun_ref(&Value::ChangeTo), 7));

return 0;
}

Under two different compiler, the code compiles without any warnings
or errors. A third compiler produces an error with output like the
following:

error: 'std::mem_fun1_ref_t<void,class Value,int>::operator`()'' :
cannot convert parameter 1 from 'const
std::binder2nd<_Fn2>::argument_type' to 'Value &' with
[
_Fn2=std::mem_fun1_ref_t<void,Value,int>
]
Conversion loses qualifiers while compiling class-template member
function 'std::binder2nd<_Fn2>::result_type
std::binder2nd<_Fn2>::operator ()(const
std::binder2nd<_Fn2>::argument_type &) const' with
[
_Fn2=std::mem_fun1_ref_t<void,Value,int>
]
see reference to class template instantiation 'std::binder2nd<_Fn2>'
being compiled with
[
_Fn2=std::mem_fun1_ref_t<void,Value,int>
]

Is this a valid error?
What can I do to fix the problem?
Jul 22 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
In article <a4**************************@posting.google.com >,
tr*********@verizon.net (Tron Thomas) wrote:
Given the following code:

#include <vector>
#include <algorithm>
#include <functional>

class Value
{
public:
explicit Value(int value) : m_value(value) {}
void ChangeTo(int value) { m_value = value; }

private:
int m_value;
};

int main()
{
std::vector<Value> values;
values.insert(values.end(), 5, Value(6));

std::for_each(values.begin(), values.end(),
std::bind2nd(std::mem_fun_ref(&Value::ChangeTo), 7));

return 0;
}

Under two different compiler, the code compiles without any warnings
or errors. A third compiler produces an error with output like the
following:

error: 'std::mem_fun1_ref_t<void,class Value,int>::operator`()'' :
cannot convert parameter 1 from 'const
std::binder2nd<_Fn2>::argument_type' to 'Value &' with
[
_Fn2=std::mem_fun1_ref_t<void,Value,int>
]
Conversion loses qualifiers while compiling class-template member
function 'std::binder2nd<_Fn2>::result_type
std::binder2nd<_Fn2>::operator ()(const
std::binder2nd<_Fn2>::argument_type &) const' with
[
_Fn2=std::mem_fun1_ref_t<void,Value,int>
]
see reference to class template instantiation 'std::binder2nd<_Fn2>'
being compiled with
[
_Fn2=std::mem_fun1_ref_t<void,Value,int>
]

Is this a valid error?
What can I do to fix the problem?


It is a valid error, but it is also a situation that the C++ standards
committee intends to address. Library issue 109,

You can find the issues list off of this page:

http://www.open-std.org/jtc1/sc22/wg21/

but as I write this, the site is down.

109 has WP status will cause your code to compile and run as expected.
This means that the committee has accepted it into the draft C++0X
standard. So technically, 109 isn't standard now, but has a good chance
of becoming so. The issue adds a non-const overload to std::binder2nd

typename Operation::result_type // experimental
operator()(typename Operation::first_argument_type& x) const
{return op(x, value);}

Apparently 2/3 of your vendors have already implemented this fix (fwiw,
Metrowerks has).

You could possibly patch your copy of std::binder2nd that hasn't yet
implemented 109.

Alternatively, you could use std::tr1::bind, or boost::bind, which I
personally find easier to use:

using namespace std::tr1::placeholders;

std::for_each(values.begin(), values.end(),
std::tr1::bind(&Value::ChangeTo, _1, 7));

std::tr1::bind is a "TR1" library that has been proposed for C++0X and
accpeted into the Library Technical Report 1. It is based on
boost::bind (www.boost.org). Your vendor may or may not yet supply
std::tr1::bind. If you use boost, then it would look like:

std::for_each(values.begin(), values.end(),
boost::bind(&Value::ChangeTo, _1, 7));

The bind function creates a function object using it's first parameter
as a function that is bound to the following parameters of bind. Those
parameters you want left unbound are designated by _1, _2, etc. When
the first parameter is a member function, then the first argument to the
resulting function object is always a pointer to (or smart pointer to,
or reference to) the object. In your example, this parameter is left
free, and the literal '7' is bound to the second parameter, resulting in
a functor that takes a single parameter: the Value&.

-Howard
Jul 22 '05 #2

P: n/a
Tron Thomas wrote:

Given the following code:

#include <vector>
#include <algorithm>
#include <functional>

class Value
{
public:
explicit Value(int value) : m_value(value) {}
void ChangeTo(int value) { m_value = value; }

private:
int m_value;
};

int main()
{
std::vector<Value> values;
values.insert(values.end(), 5, Value(6));

std::for_each(values.begin(), values.end(),
std::bind2nd(std::mem_fun_ref(&Value::ChangeTo), 7));

return 0;
}

Under two different compiler, the code compiles without any warnings
or errors. A third compiler produces an error with output like the
[...]
Is this a valid error?
Yes, but... the issue is in the Standard Library Defect Report List:
http://www.open-std.org/jtc1/sc22/wg...fects.html#109

Some popular implementations already address it by including an
as of yet non-standard binder2nd::operator() for non-const
arguments.
What can I do to fix the problem?


You can write your own binder if your library doesn't implement
the proposed resolution.

Denis
Jul 22 '05 #3

P: n/a
Thanks Howard and Denis for you replies. This has clear things up. I
solved the problem by just not using an binder and implementing my own
functor to pass into for_each.

I played around with the original code and the compilers (or STL
implementaions) that could successfully compile that code. I
discovered that for one implementation the values in the container
were modified, and for the other implementation the values were not
modified. Does this imply a bug in the implementation where the
values were not modified?
Jul 22 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.