C++ library design (was: Re: Expanding the list of "Hardened Packages")
fweimer at redhat.com
Fri May 17 12:08:23 UTC 2013
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:
>> 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
Florian Weimer / Red Hat Product Security Team
More information about the devel