[Bug c++/37811] New: bind1st fails on mem_fun with reference argument

[Bug c++/37811] New: bind1st fails on mem_fun with reference argument

[igodard at pacbell dot net]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2845 bytes --]

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.


-- 
           Summary: bind1st fails on mem_fun with reference argument
           Product: gcc
           Version: 4.3.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: igodard at pacbell dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811

[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2008-10-13 08:44 -------
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.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
          Component|c++                         |libstdc++
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811

[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument

[igodard at pacbell dot net]

------- Comment #2 from igodard at pacbell dot net  2008-10-13 15:18 -------
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


-- 

igodard at pacbell dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811

[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument

[paolo dot carlini at oracle dot com]

------- Comment #3 from paolo dot carlini at oracle dot com  2008-10-13 15:27 -------
(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.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811

[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument

[igodard at pacbell dot net]

------- Comment #4 from igodard at pacbell dot net  2008-10-13 16:06 -------
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? 


-- 

igodard at pacbell dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |igodard at pacbell dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811

[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument

[paolo dot carlini at oracle dot com]

------- Comment #5 from paolo dot carlini at oracle dot com  2008-10-13 16:23 -------
(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...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811

[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument

[igodard at pacbell dot net]

------- Comment #6 from igodard at pacbell dot net  2008-10-13 17:01 -------
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?


-- 

igodard at pacbell dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811

[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument

[paolo dot carlini at oracle dot com]

------- Comment #7 from paolo dot carlini at oracle dot com  2008-10-13 17:13 -------
(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.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811

[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument

[igodard at pacbell dot net]

------- Comment #8 from igodard at pacbell dot net  2008-10-13 17:55 -------
OK, thanks for your time.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811

[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument

[paolo dot carlini at oracle dot com]

------- Comment #9 from paolo dot carlini at oracle dot com  2008-10-13 19:07 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811