Re: std::equal bombs if the

[Sebastian Redl <sebastian dot redl at getdesigned dot at>]

Smith-Rowland, Edward M wrote:
> Hi,
>
> I'm working on an implementation of std::forward_list and bumped into something while testing equality of containers:
>
> bool eq = std::equal(firsst1, lasst1, firsst2);
>
> this will bomb if the number of elements in [firsst1, lasst1)
> is greater than in [firsst2, firsst2 + distance(firsst1, lasst1)).
>
> The standard seemed to me to be quiet on this but mightn't it be a good idea to watch out that lasst2 doesn't hit the end() of the second list?
>   
How?
> Maybe the powers that be didn't want the time overhead of the check?
>
> Is this the way it's supposed to be or is it a bug?
>
> The whole issue turned up for me because forward_list doesn't have size() so I wound up having to walk through and watch out for end() in both lists.  The other containers check size() of the two containers.
>   
It's a very weird specification by the standard, and I consider the lack 
of an equal (and a mismatch) with two iterator pairs as input a serious 
deficiency (especially since both sequences might be single-traversal 
and of unknown length), but it's not a bug of the GCC implementation.

You can abuse search to the purpose of having an equal that takes the 
lengths of both sequences, but it also may return incorrect results in 
respect to the equal specification.
You can also use lexicographical_compare to that purpose, at twice the 
computational expense, of course.

Sebastian