On 05/17/2013 07:17 AM, Ben Boeckel wrote:
While we're dredging up old threads ;) .
On Fri, 10 May, 2013 at 12:29:16 GMT, Florian Weimer wrote:
> There is some fairly horrible stuff, like std::copy:
>
> <
http://en.cppreference.com/w/cpp/algorithm/copy>
>
> You can pass a std::vector<T>::iterator (say, the result of begin()) as
> the output iterator, but it's your job to ensure that there's enough
> space. Just like strcpy, and we all know how well that worked in practice.
Well, the STL has a solution for that, but the header is, unfortunately,
underused IME.
#include <iterator>
std::copy(src.begin(), src.end(), std::back_inserter(dest));
That said, I do wish there were a "InsertIterator" concept or the like
which std::copy would require (and probably move the existing std::copy
to std::unsafe_copy if it's deemed required still).
True, and even if std::back_inserter didn't exist, you could roll your
own. I guess that's one of the strengths of the standard container library.
But I really dislike the concept of iterators, that is, lightweight
pointer-like objects that can be copied cheaply and do not keep, by
themselves, the pointed-to data structures alive. Some ABIs even treat
classes with just one scalar member as scalars themselves, so that they
can be passed in registers, and for a long time, GCC only performed
scalar replacement for single-member classes, so the impact of this
design decision has been quite pervasive.
There are safer abstractions than iterators. If you try to translate
iterators to a memory-safe language, you are forced to combine iterators
in pairs, like quarks (sometimes called "ranges"). That might be a
better choice for C++ as well, especially if you discourage copying, so
that the construction/destruction overhead does not come into play that
much.
--
Florian Weimer / Red Hat Product Security Team