This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch] First bits of the algo merge
On Dec 15, 2005, at 12:39 PM, Paolo Carlini wrote:
Howard Hinnant wrote:
I'd like to ask your opinion (guess) about these two related issues:
1- Using strumentally the improved algorithm simplification
strategy is
the only relatively simple way to substantially improve on that QoI
issue or you can imagine/suggest other (better?) ways?
Sorry, I'm not completely parsing this one.
I thought it was clear that simplifying the algorithms by way of
the new
__ops::equal_to & co actually *improved* our QoI wrt proxy
iterators. Or
is that wrong? Maybe it's wrong, because you want to work on showing
that B is non-conforming?!?
So, let me ask my question in a different, basic, way: let's
suppose we
want to just *improve* our implementation from every point of view,
without regressions, what do you suggest?? You understand, so far
is not
so clear from your messages... ;)
Paolo.
Ah ok. I'm coming around. Just had to step out and jump-start my
brain is all. ;-)
Imho, and as far as I know for now, B and C are both better than A
from the viewpoint of supporting proxy iterators (which can be
conforming input iterators). B is better than C from a maintenance
and reliability point of view (gets rid of source code duplication,
halving the chance for bugs). If no one can show that B is worse
than C from a conformance, or even usability point of view, then I
think B is the clear winner. However it would be irresponsible of me
to not try and discredit B. But unfortunately I have a bias that I
hope I can't, as I think its other advantages over C are
significant. I will do my best to not let my bias get in the way of
my research.
But since you asked for other improvement ideas... ;-)
Just kidding. I've probably done enough damage for one day, at least
in this area. I am about to suggest a tiny patch in a different
area... (stdexcept for the incurably curious).
-Howard