--- 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
--- 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
--- 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
--- 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.
--
--- 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 [EMAIL PROTECTED] writes:
| No, I don't. The standard is clear and most of us seem to think it's by
| design. Rather
--- 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,
--- 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
--- 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 [EMAIL PROTECTED] writes:
| 2- As I see the issue, it depends a lot on the actual timeframe of
| the possible
--- 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
;-)
--- 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 [EMAIL PROTECTED] writes:
| + the more general consideration that, delivering a C++0x conforming
| library certainly
--- 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.
--- 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
--- 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?
--
--- 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
--- 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 [EMAIL PROTECTED] writes:
| Related to PR 16505. This is the same issue as PR 16505.
|
| Can someone close to
--- 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
--- 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
--- 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
--- 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 [EMAIL PROTECTED] writes:
| FWIW, I think Andrew makes a good point in comment #1. The algorithms really
| should
19 matches
Mail list logo
