[Bug libstdc++/25304] New: std::fill_n, std::generate_n incorrect signature

[Bug libstdc++/25304] New: std::fill_n, std::generate_n incorrect signature

[sebor at roguewave dot com]

Both template functions are required to return void.

$ cat u.cpp && g++ -c u.cpp
#include <algorithm>

template void std::fill_n (int*, int, const int&);
template void std::generate_n (int*, int, int (*)());

int main () { }
u.cpp:3: error: template-id 'fill_n<>' for 'void std::fill_n(int*, int, const
int&)' does not match any template declaration
u.cpp:4: error: template-id 'generate_n<>' for 'void std::generate_n(int*, int,
int (*)())' does not match any template declaration


-- 
           Summary: std::fill_n, std::generate_n incorrect signature
           Product: gcc
           Version: 4.0.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sebor at roguewave dot com
 GCC build triplet: all
  GCC host triplet: all
GCC target triplet: all


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-07 22:21 -------
Hmm, SGI's stl had them returning a value.  This is really weird it changed
from returning a value to not to returning a value.  Maybe this was a mistake
in the standard to do that or maybe libstdc++ is just wrong.  I wished that
standard had not changed this.


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2005-12-07 22:23 -------
http://www.sgi.com/tech/stl/generate_n.html
http://www.sgi.com/tech/stl/fill_n.html


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2005-12-07 22:26 -------
Related to PR 16505.  This is the same issue as PR 16505.

Can someone close to the standard answer the question why did they change the
return type for these functions?


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[pcarlini at suse dot de]

------- Comment #4 from pcarlini at suse dot de  2005-12-07 23:39 -------
In any case, it's a bug. I'm only not sure whether, similarly to the story of
16505, we want to fix it and break user code relying on non standard conforming
behavior. I'm in favor of fixing this problem too, for 4.2 only of course,
nobody complained about the resolution of 16505.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-12-07 23:39:53
               date|                            |


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[gdr at integrable-solutions dot net]

------- Comment #5 from gdr at integrable-solutions dot net  2005-12-07 23:42 -------
Subject: Re:  std::fill_n, std::generate_n incorrect signature

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| Related to PR 16505.  This is the same issue as PR 16505.
| 
| Can someone close to the standard answer the question why did they change the
| return type for these functions?

I think it really does not matter now -- many things changed when they
got their way into the standard, for more or less obvious reasons.
We've gotten a bug in libstdc++. 

-- Gaby


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[pcarlini at suse dot de]

------- Comment #6 from pcarlini at suse dot de  2005-12-08 00:01 -------
Agreed.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
                   |dot org                     |
             Status|NEW                         |ASSIGNED


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[sebor at roguewave dot com]

------- Comment #7 from sebor at roguewave dot com  2005-12-08 00:08 -------
FWIW, I think Andrew makes a good point in comment #1. The algorithms really
should return the iterator, otherwise the caller may not be able to find out
the state of the iterator after the algorithm returns (e.g., when the iterator
is ostreambuf_iterator). It may not be a bad idea to open an issue (or at least
bring it up on the reflector).


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[pcarlini at suse dot de]

------- Comment #8 from pcarlini at suse dot de  2005-12-08 00:20 -------
(In reply to comment #7)
> FWIW, I think Andrew makes a good point in comment #1. The algorithms really
> should return the iterator, otherwise the caller may not be able to find out
> the state of the iterator after the algorithm returns (e.g., when the iterator
> is ostreambuf_iterator).

Ah, I see. Then the issue is more subtle than uninitialized_fill_n in 16505...

> It may not be a bad idea to open an issue (or at least
> bring it up on the reflector).

Ok, I will, if you don't beat me ;)


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[gdr at integrable-solutions dot net]

------- Comment #9 from gdr at integrable-solutions dot net  2005-12-08 03:32 -------
Subject: Re:  std::fill_n, std::generate_n incorrect signature

"sebor at roguewave dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| FWIW, I think Andrew makes a good point in comment #1. The algorithms really
| should return the iterator, otherwise the caller may not be able to find out
| the state of the iterator after the algorithm returns (e.g., when the
iterator
| is ostreambuf_iterator). It may not be a bad idea to open an issue (or at
least
| bring it up on the reflector).

So do you suggest to get this PR in suspended state and get feedback
from LWG?

-- Gaby


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[sebor at roguewave dot com]

------- Comment #10 from sebor at roguewave dot com  2005-12-08 15:51 -------
No, I don't. The standard is clear and most of us seem to think it's "by
design." Rather I am suggesting is that we might want to discuss with the whole
LWG changing the return type as an enhancement.


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[gdr at integrable-solutions dot net]

------- Comment #11 from gdr at integrable-solutions dot net  2005-12-08 16:04 -------
Subject: Re:  std::fill_n, std::generate_n incorrect signature

"sebor at roguewave dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| No, I don't. The standard is clear and most of us seem to think it's "by
| design." Rather I am suggesting is that we might want to discuss with the
whole
| LWG changing the return type as an enhancement.

I think I understand that.  

However, I'm looking at the pratical effect.  If libstdc++ changes the
return types (correcting the bug) then it will be an ABI breakage.
If LWG considers and agrees on the enhancement, libstdc++ will have to
change again the return types.  At the end of the day we would have
two ABI breakages with zero net benefit for existing libstdc++ users.

-- Gaby


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[pcarlini at suse dot de]

------- Comment #12 from pcarlini at suse dot de  2005-12-08 16:11 -------
(In reply to comment #11)
> However, I'm looking at the pratical effect.  If libstdc++ changes the
> return types (correcting the bug) then it will be an ABI breakage.
> If LWG considers and agrees on the enhancement, libstdc++ will have to
> change again the return types.  At the end of the day we would have
> two ABI breakages with zero net benefit for existing libstdc++ users.

I share your concerns. Want to add a couple of thoughts:
1- When we broke the ABI to fix 16505, I think we did that with the spirit that
it was a, so to speak, "weak" breakage, because could possibly byte only people
using the return value, something not standard conforming. Indeed, we received
zero complaints, as I already remarked.
2- As I see the issue, it depends a lot on the actual timeframe of the possible
enhancement to the standard. I mean, if we are thinking about C++0x, seems
rather far in time. I think most of our users would not perceive our practice
as randomly going back and forward on something.


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[pcarlini at suse dot de]

------- Comment #13 from pcarlini at suse dot de  2005-12-08 16:20 -------
(In reply to comment #12)

> 2- As I see the issue, it depends a lot on the actual timeframe of the possible
> enhancement to the standard. I mean, if we are thinking about C++0x, seems
> rather far in time. I think most of our users would not perceive our practice
> as randomly going back and forward on something.

+ the more general consideration that, delivering a C++0x conforming library
certainly will involve breaking the ABI in tens of different ways (e.g., I have
in front of me the implementation of DR 130, only a very simple and relatively
trivial example).


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[gdr at integrable-solutions dot net]

------- Comment #14 from gdr at integrable-solutions dot net  2005-12-08 16:23 -------
Subject: Re:  std::fill_n, std::generate_n incorrect signature

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| 2- As I see the issue, it depends a lot on the actual timeframe of
| the possible enhancement to the standard. I mean, if we are thinking
| about C++0x, seems rather far in time. I think most of our users
| would not perceive our practice as randomly going back and forward
| on something. 

Fair enough.

(At Lillehammer, we set to have x, in C++0x, a digit; so that means
we're almost done by 2007.  That is not far, given that LWG would not
need to wait 2007 before agreeing on the issue.  I was amazed to
discover that CWG two two meetings to open an issue and move it to WP.
LWG could do the same.  Hint, hint, :-))

-- Gaby


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[sebor at roguewave dot com]

------- Comment #15 from sebor at roguewave dot com  2005-12-08 16:27 -------
(In reply to comment #11)

Okay, I see your concern.

Well, IMO, your signatures are better than those required by the standard so if
you care about 100% compliance you (or Paolo -- and I promise not to beat him
;-) should open an issue with the LWG and try to get the standard changed. I
will support the change. Until the LWG issue is resolved (and hopefully even
after that) you can leave your signatures alone.


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[gdr at integrable-solutions dot net]

------- Comment #16 from gdr at integrable-solutions dot net  2005-12-08 17:12 -------
Subject: Re:  std::fill_n, std::generate_n incorrect signature

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| + the more general consideration that, delivering a C++0x conforming
| library certainly will involve breaking the ABI in tens of different
| ways 

I have no trouble with that.
My main concern is whether the flip flop worths it *if* we're going to
change back.

-- Gaby


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[chris at bubblescope dot net]

------- Comment #17 from chris at bubblescope dot net  2006-01-04 13:53 -------
Just as a quick note, I've personally got code using the non-void return value
of generate_n (because I'm going along a list, and didn't want to have to
incremement n steps after filling the list, as that would cost). Not that I'm
saying that means the code should stay, just at least one data point of someone
who is using the current version :)


-- 

chris at bubblescope dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chris at bubblescope dot net


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[pcarlini at suse dot de]

------- Comment #18 from pcarlini at suse dot de  2006-01-04 13:58 -------
(In reply to comment #17)
>                                                                    Not that I'm
> saying that means the code should stay, just at least one data point of someone
> who is using the current version :)

Thanks. By now, I think we agree that first we want to raise the issue with the
LWG. I promise to do something in time for Berlin, at least.


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[pcarlini at suse dot de]

------- Comment #19 from pcarlini at suse dot de  2006-02-26 10:09 -------
For now...


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |SUSPENDED


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

[Bug libstdc++/25304] [DR 865] std::fill_n, std::generate_n incorrect signature

[paolo dot carlini at oracle dot com]

------- Comment #20 from paolo dot carlini at oracle dot com  2009-12-14 23:26 -------
This is in fact DR 865 and now that the status is [Ready] we can simply re-open
it, say in the docs that we implement it already and then close it again.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW
   Last reconfirmed|2005-12-07 23:39:53         |2009-12-14 23:26:16
               date|                            |
            Summary|std::fill_n, std::generate_n|[DR 865] std::fill_n,
                   |incorrect signature         |std::generate_n incorrect
                   |                            |signature


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

[Bug libstdc++/25304] [DR 865] std::fill_n, std::generate_n incorrect signature

[paolo at gcc dot gnu dot org]

------- Comment #21 from paolo at gcc dot gnu dot org  2009-12-15 00:08 -------
Subject: Bug 25304

Author: paolo
Date: Tue Dec 15 00:07:52 2009
New Revision: 155241

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155241
Log:
2009-12-14  Paolo Carlini  <paolo.carlini@oracle.com>

        PR libstdc++/25304, DR 865 [Ready]
        * include/bits/stl_algobase.h (fill_n): Add comment about DR 865.
        * include/bits/stl_algo.h (generate_n): Likewise.
        * include/bits/algorithmfwd.h: Remove obsolete comment.
        * doc/xml/manual/intro.xml: Add an entry for DR 865.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/doc/xml/manual/intro.xml
    trunk/libstdc++-v3/include/bits/algorithmfwd.h
    trunk/libstdc++-v3/include/bits/stl_algo.h
    trunk/libstdc++-v3/include/bits/stl_algobase.h


-- 


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

[Bug libstdc++/25304] [DR 865] std::fill_n, std::generate_n incorrect signature

[paolo dot carlini at oracle dot com]

------- Comment #22 from paolo dot carlini at oracle dot com  2009-12-15 00:10 -------
Done.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


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