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

Reply via email to