[Bug libstdc++/39136] New: std::mem_fun_ref fails to accept a member function whose second argument with default value

[Bug libstdc++/39136] New: std::mem_fun_ref fails to accept a member function whose second argument with default value

[fang at csl dot cornell dot edu]

std::mem_fun_ref fails to accept a member function whose second argument can be
bound to a default value.  In this example, I use vector<>::resize.  

Test case:
#include <vector>
#include <functional>
#include <algorithm>

using std::vector;
using std::mem_fun_ref;
using std::bind2nd;
using std::for_each;

typedef vector<int>             int_vec;
Test case:

typedef vector<int_vec>         matrix;

void
test(void) {
        matrix M;
        M.resize(4);
        for_each(M.begin(), M.end(),
                bind2nd(mem_fun_ref(&int_vec::resize), 4));
}

Compile: g++ -O3 -W -Wall -Werror -ansi -pedantic-errors  -c vector.cc -o
vector.o

Diagnostic:
vector.cc: In function 'void test()':
vector.cc:18: error: no matching function for call to 'mem_fun_ref(void
(std::vector<int, std::allocator<int> >::*)(long unsigned int, int))'
make: *** [vector.o] Error 1

Known to "work": 4.0.1
Fail: 4.3.2 4.3.3

I'm not sure if this is valid code.  However, the standard seems to indicate
that resize(size_type), is a required member function (or at least interface)
of std::vector.  Does the standard (20.6.13) allow mem_fun_ref and such to bind
to member functions with default values in the tail position?


-- 
           Summary: std::mem_fun_ref fails to accept a member function whose
                    second argument with default value
           Product: gcc
           Version: 4.3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: fang at csl dot cornell dot edu


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

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

[fang at csl dot cornell dot edu]

------- Comment #1 from fang at csl dot cornell dot edu  2009-02-09 07:39 -------
also "Fails": 4.2.4


-- 


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

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

[paolo dot carlini at oracle dot com]

------- Comment #2 from paolo dot carlini at oracle dot com  2009-02-09 09:53 -------
(In reply to comment #0)
> I'm not sure if this is valid code.  However, the standard seems to indicate
> that resize(size_type), is a required member function (or at least interface)
> of std::vector. 

Which standard? To be clear, in the current one, the function is
resize(size_type sz, T c = T()).

Otherwise, the C++0x overloads require concepts (and I think we also have an
open PR about that)


-- 


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

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

[fang at csl dot cornell dot edu]

------- Comment #3 from fang at csl dot cornell dot edu  2009-02-09 15:58 -------
Subject: Re:  std::mem_fun_ref fails to accept a member
 function whose second argument with default value

> ------- Comment #2 from paolo dot carlini at oracle dot com  2009-02-09 09:53 -------
> (In reply to comment #0)
>> I'm not sure if this is valid code.  However, the standard seems to indicate
>> that resize(size_type), is a required member function (or at least interface)
>> of std::vector.
>
> Which standard? To be clear, in the current one, the function is
> resize(size_type sz, T c = T()).

I'm looking at the current draft, n2798.
23.2.6.2/10-11 [vector.capacity]
which lists both forms of resize().
Yes, libstdc++ covers both by using the trailing default argument, but I 
still can't pass it to mem_fun/mem_fun_ref.

Compilation still fails with both -std=c++0x and -std=c++98 with the 
above test case.  (Test case contains a stray line "Test case:" from 
mis-pasting, my bad.)

> Otherwise, the C++0x overloads require concepts (and I think we also have an
> open PR about that)

Got a PR reference handy?

Fang

David Fang
http://www.csl.cornell.edu/~fang/
http://www.achronix.com/


-- 


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

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

[paolo dot carlini at oracle dot com]

------- Comment #4 from paolo dot carlini at oracle dot com  2009-02-09 16:11 -------
(In reply to comment #3)
> I'm looking at the current draft, n2798.
> 23.2.6.2/10-11 [vector.capacity]
> which lists both forms of resize().
> Yes, libstdc++ covers both by using the trailing default argument, but I 
> still can't pass it to mem_fun/mem_fun_ref.

To be clear again: the current draft is not relevant here, because we are *not*
implementing it. Concepts are needed, see PR 32618.

Thus, since we are strictly following the standard as far as std::vector is
concerned, I have troubles believing that the implementation of mem_fun_ref is
at fault in any sense, that is really old code, and following rather directly
from the specs. Either a C++ issue, or not a bug. Please double check.


-- 


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

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

[paolo dot carlini at oracle dot com]

------- Comment #5 from paolo dot carlini at oracle dot com  2009-02-09 16:47 -------
Your snippet boils down to this, which is clearly invalid:

struct vector
{
  void resize(long unsigned int, int = 0);
};

template<typename _Ret, typename _Tp, typename _Arg>
  void
  mem_fun_ref(_Ret (_Tp::*__f)(_Arg));

void
test() {
  mem_fun_ref(&vector::resize);
}


-- 

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=39136

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

[fang at csl dot cornell dot edu]

------- Comment #6 from fang at csl dot cornell dot edu  2009-02-09 17:21 -------
Subject: Re:  std::mem_fun_ref fails to accept a member
 function whose second argument with default value

> ------- Comment #5 from paolo dot carlini at oracle dot com  2009-02-09 16:47 -------
> Your snippet boils down to this, which is clearly invalid:
>
> struct vector
> {
>  void resize(long unsigned int, int = 0);
> };
>
> template<typename _Ret, typename _Tp, typename _Arg>
>  void
>  mem_fun_ref(_Ret (_Tp::*__f)(_Arg));
>
> void
> test() {
>  mem_fun_ref(&vector::resize);
> }

Fair enough, that's what I wanted to know.

I suppose mem_fun_ref(&vector::resize) just *happened* to be accepted in 
earlier versions of libstdc++, when it was never required to do so.

The following declaration was what allowed it to do so.
// 4.0.1 <bits/stl_vector.h>
// class vector {
       void
       resize(size_type __new_size)
       { resize(__new_size, value_type()); }
// };

Was there a compelling reason to remove it in favor of the unified
::resize(size_type, const value_type& t = T)?

Anyhow, thanks for the feedback!


Fang


-- 


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

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

[paolo dot carlini at oracle dot com]

------- Comment #7 from paolo dot carlini at oracle dot com  2009-02-09 17:26 -------
(In reply to comment #6)
> Was there a compelling reason to remove it in favor of the unified
> ::resize(size_type, const value_type& t = T)?

Yes, is non-conforming! I thought it was clear at this point... Just try to
instantiate that version of std::vector with a non-DefaultConstructible Tp!


-- 


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

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

[fang at csl dot cornell dot edu]

------- Comment #8 from fang at csl dot cornell dot edu  2009-02-09 17:54 -------
Subject: Re:  std::mem_fun_ref fails to accept a member
 function whose second argument with default value

> ------- Comment #7 from paolo dot carlini at oracle dot com  2009-02-09 17:26 -------
> (In reply to comment #6)
>> Was there a compelling reason to remove it in favor of the unified
>> ::resize(size_type, const value_type& t = T)?
>
> Yes, is non-conforming! I thought it was clear at this point... Just try to
> instantiate that version of std::vector with a non-DefaultConstructible Tp!

At no point was vector<Tp>::resize() ever instantiatable with a 
non-DefaultConstructible Tp, even with the old size_type-only member 
function.  It would have failed on value_type() in the definition body.
That doesn't make it any less conforming, does it?

The default-tail-argument version of ::resize() (with = Tp()) just fails 
at the prototype in a concept-way, rather than through body instantiation.
Is that the critical difference?

Fang


-- 


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

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

[paolo dot carlini at oracle dot com]

------- Comment #9 from paolo dot carlini at oracle dot com  2009-02-09 17:59 -------
(In reply to comment #8)
> At no point was vector<Tp>::resize() ever instantiatable with a 
> non-DefaultConstructible Tp, even with the old size_type-only member 
> function.  It would have failed on value_type() in the definition body.
> That doesn't make it any less conforming, does it?

I do not understand what you are saying: a std::vector strictly following the
current, C++03 specifications, can be explicitly instantiated for a
non-DefaultConstructible Tp. And indeed, this is what happens with current v3,
and was *not* happening back in the 4.0 time.

In C++0x, thanks to Concepts, that will be also true, it will be possible to
explicitly instantiate std::vector for a non-DefaultConstructible Tp and, plus,
it will possible to have 2 separate, optimized, overloads. 

I don't see any other option.


-- 


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

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2009-02-10 22:03 -------
Reopening to ...


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2009-02-10 22:03 -------
Mark this as a dup of bug 37088.

*** This bug has been marked as a duplicate of 37088 ***


-- 

pinskia at gcc dot gnu dot org changed:

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


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