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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
