This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: reducing needless normal_iterator usage in vector
- From: Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>
- To: libstdc++ at gcc dot gnu dot org
- Date: Wed, 03 Jul 2002 18:29:38 +0200
- Subject: Re: reducing needless normal_iterator usage in vector
[Sorry if this gets duplicated, the initial E-mail bounced, since it
has not appeared for one hour, I'm re-sending it ].
phil@jaj.com said:
> That would not affect the internals at all. We must always use a
> simple pointer in the underlying operations, just because we're
> required to use contiguous storage in a vector. The external iterator
> implementation can be normal_iterator or anything more complicated;
> that has nothing to do with it. I'm saying that we don't need to use
> any of that for the internals.
Note that I'm playing the devil's advocate here...
1) You say yourself that:
> typing "begin()" was simply clearer code.
and I think this is true.
2) I also think it allows for more flexibility (I agree that the
following is a contrieved example though). Imagine that I want to check which
elements in the vector are used. Currently (and this is clearly an
abuse but we might also call it QOI), I can give a new definition for
normal_iterator (or a specialization) that does the book keeping
since all accesses for the vector elements go through an iterator.
3) IMHO, the library should be written as cleanly and clearly as possible.
The kind of optimization you suggest can be done by the compiler (and indeed
it does it at -O2 as far as I understood). Not that I suggest that no optimization
should be done at the library level, but merely that those that can be done in the
compiler should be done by the compiler. One benefit of this is that
all the code (optimized in the way you propose or not) will benefit
from it instead of only code written by knowledgeable people that are
careful (as you are) enough to look at the assembly code for a given
construct. In this case, I would say that both ways of coding should
trivially give equivalent results, so it's the compiler's work (as
opposed to the library implementer's) to do the job. [ Just to be very
clear, this is certainly not a criticism of the compiler or of the compiler
people, which do a great job. ]
IMHO, the best suggestion about the problem you raised is to fill
a gnats report as a QOI issue.
People that want the optimization will compile with -O2 anyhow.
Theo.
--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
--------------------------------------------------------------------