C++ library design (was: Re: Expanding the list of "Hardened Packages")

[Florian Weimer]

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