This code: #include <functional> class Foo { public: void F(int i) {} void G(int& i) {} void H(int* i) {} }; void bar () { Foo f; Foo* fs; std::mem_fun(&Foo::F); std::mem_fun(&Foo::G); std::mem_fun(&Foo::H); std::bind1st(std::mem_fun(&Foo::F), fs); std::bind1st(std::mem_fun(&Foo::G), fs); std::bind1st(std::mem_fun(&Foo::H), fs); std::bind1st(std::mem_fun_ref(&Foo::F), f); std::bind1st(std::mem_fun_ref(&Foo::G), f); std::bind1st(std::mem_fun_ref(&Foo::H), f); } compiles on Comeau. On gcc it gets you: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward/binders.h: In instantiation of ‘std::binder1st<std::mem_fun1_t<void, Foo, int&> >’: foo.cc:16: instantiated from here /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward/binders.h:120: error: ‘typename _Operation::result_type std::binder1st<_Operation>::operator()(typename _Operation::second_argument_type&) const [with _Operation = std::mem_fun1_t<void, Foo, int&>]’ cannot be overloaded /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward/binders.h:114: error: with ‘typename _Operation::result_type std::binder1st<_Operation>::operator()(const typename _Operation::second_argument_type&) const [with _Operation = std::mem_fun1_t<void, Foo, int&>]’ /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward/binders.h: In instantiation of ‘std::binder1st<std::mem_fun1_ref_t<void, Foo, int&> >’: foo.cc:19: instantiated from here /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward/binders.h:120: error: ‘typename _Operation::result_type std::binder1st<_Operation>::operator()(typename _Operation::second_argument_type&) const [with _Operation = std::mem_fun1_ref_t<void, Foo, int&>]’ cannot be overloaded /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.1/../../../../include/c++/4.3.1/backward/binders.h:114: error: with ‘typename _Operation::result_type std::binder1st<_Operation>::operator()(const typename _Operation::second_argument_type&) const [with _Operation = std::mem_fun1_ref_t<void, Foo, int&>]’ Note that only the member functions with a reference parameter fail; pass by value and pass by pointer are accepted.
Apparently the other library doesn't implement the resolution of DR 109 (if I comment out the additional operator() the code compiles). In any case, there are very long standing issues with those facilities, which will be deprecated in C++0x (we already moved the code to include/backward/) and replaced by bind.
Deprecated or not, shouldn't it work up until when it is actually removed? And forgive me, but I don't understand the relevance of DR 109 here. Perhaps you meant some other number? Lastly, if this is not a compiler issue should I file it against c++lib instead? Ivan
(In reply to comment #2) > Deprecated or not, shouldn't it work up until when it is actually removed? It works perfectly well, as designed, without regressions, it's just that implementing the resolution of library DR 109: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109 causes this rejection. As I said already, these issues are *known* by the Committee and that's why those facilities are considered unreparably flawed in general, thus deprecated, and replaced by bind in C++0x.
Ah - I was looking at language DR109, not library DR109. However, the correct DR says the committee approved the example reported here (and adds the fix) so gcc appears to be in error to fail it. However, there is the curious remark: "Howard believes there is a flaw in this resolution. See c++std-lib-9127. We may need to reopen this issue." Unfortunately Google turns up nothing for "c++std-lib-9127" except this cryptic message, and just "9127" and other variations aren't productive either. Can you tell me where to find it?
(In reply to comment #4) > Ah - I was looking at language DR109, not library DR109. However, the correct > DR says the committee approved the example reported here (and adds the fix) so > gcc appears to be in error to fail it. That't *not* true. The example in DR 109 does *not* compile if the additional operator() are not added and does when the resolution of DR 109 is implemented. However, there is the curious remark: > "Howard believes there is a flaw in this resolution. See c++std-lib-9127. > We may need to reopen this issue." In any case, this is moot. As I tried to explain, nobody really cares these days about those bind1st and bind2nd binders, in the CD1 C++0x are already in an appendix, as deprecated features, with the exact resolution of issue DR 109 included, as we are doing. > Unfortunately Google turns up nothing for "c++std-lib-9127" except this cryptic > message, and just "9127" and other variations aren't productive either. Can you > tell me where to find it? It's a message to the ISO library reflector. Really, given the above, I would suggest not wasting further time...
Then I'm hopelessly confused. It's clear that my report and the example in DR109 are the same problem. You say: "The example in DR 109 does *not* compile if the additional operator() are not added and does when the resolution of DR 109 is implemented." That makes sense - with the addition of the overload my example will compile too. So it appears that gcc (at least 4.3.1) does *not* implement DR109. You then say, in essence, "So what, it's deprecated in C++0X and there's a better solution therein, get over it". Would that I could! Unfortunately, out here in the real world some of us have legal, business, and practical mandates that *require* us to use only *officially issued* language standards, and explicitly prohibit us from using extensions, next-release features and so on. On pain of being fired, if not worse. I realize that keeping up with soon-to-be-obviated DRs is not the most professionally satisfying activity. But the fix here seems so well known and trivial that I don't understand a reluctance to put it in. However, gcc is a volunteer project and if nobody will put it in then nobody will put it in. May I suggest that the proper resolution of my report is "VERIFIED - WONT FIX"? Or perhaps I've again misunderstood?
(In reply to comment #6) > Then I'm hopelessly confused. It's clear that my report and the example in > DR109 are the same problem. You say: "The example in DR 109 does *not* compile > if the additional operator() are not added and does when the resolution of DR > 109 is implemented." That makes sense - with the addition of the overload my > example will compile too. So it appears that gcc (at least 4.3.1) does *not* > implement DR109. No!!!! It does *exactly* implement the DR, it SIMPLY adds the two operator(). Your problem is totally different, has to do with the obnoxious reference to reference issue, which plagued C++03. The overloads are already there, check again in the code of the library, but are there to fix a completely different issue, that reported in DR 109, which has to do with non-const members. Please, do not re-open PR at your will. This issue is absolutely clear to the maintainers of the library and nobody (I repeat nobody) will take any further real action, irrespective of you reopening it or not.
OK, thanks for your time.
FYI, I had a quick look to the library likely used by current Comeau: it doesn't implement the letter of the Standard for bind1st & co, neither before nor after DR 109. It tries to circumvent the limitations of the original design. To be clear again, we'll not follow that route, we deliver a strictly conforming implementation, DR 109 included and included the fact that the facility is considered deprecated, essentially frozen and ready for removal.