This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/26020] std::advance() isn't stable for floating point numbers
- From: "gdr at integrable-solutions dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 30 Jan 2006 01:05:24 -0000
- Subject: [Bug libstdc++/26020] std::advance() isn't stable for floating point numbers
- References: <bug-26020-8082@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #7 from gdr at integrable-solutions dot net 2006-01-30 01:05 -------
Subject: Re: std::advance() isn't stable for floating point numbers
"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:
| ------- Comment #5 from pcarlini at suse dot de 2006-01-30 00:45 -------
| (In reply to comment #4)
| > | AFAICS, the standard is silent about this issue. I think the suggested
| > | change is correct.
| >
| > I believe Martin Sebor filled a related PR, whereby we should have
| > converted n to *some* integral type before proceeding...
|
| I was also under that impression. That issue, however, was about Size in
algos,
sorry; memory failing.
| which, at least, is required to be convertible to an integral type. I don't
| think we even have such *minimal* requirement here... What do you suggest?
reading the standard specification let me under the impression that
Distance is supposed to "related" to difference_type. For example
the distance between the p before and after calling distance(p, n) is
supposed to be n. So I would suggest conversion to the
difference_type of the iterator as a momentary resolution.
| Should the LWG discuss such kind of requirements for Distance too?
Definitely.
| In the meanwhile suspend? I have no strong opinions...
I'm not sure the resolution would introduce an ABI breakage, so I
would say let's do both; but I'm open to other alternatives.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26020