Question

std::set_union and its kin take two pairs of iterators for the sets to be operated on. That’s great in that it’s the most flexible thing to do. However they very easily could have made an additional convenience functions which would be more elegant for 80% of typical uses.

For instance:

template<typename ContainerType, typename OutputIterator>
OutputIterator set_union( const ContainerType & container1, 
                const ContainerType & container2, 
                OutputIterator      & result      )
{
    return std::set_union( container1.begin(), container1.end(), 
                           container2.begin(), container2.end(), 
                           result );
}

would turn:

std::set_union( mathStudents.begin(), mathStudents.end(), 
                physicsStudents.begin(), physicsStudents.end(), 
                students.begin() );

into:

std::set_union( mathStudents, physicsStudents, students.begin() );

So:

• Are there convenience functions like this hiding somewhere that I just haven’t found?

• If not, can anyone thing of a reason why it would be left out of STL?

• Is there perhaps a more full featured set library in boost? (I can’t find one)

I can of course always put my implementations in a utility library somewhere, but it’s hard to keep such things organized so that they’re used across all projects, but not conglomerated improperly.

Answer 1

Are there convenience functions like this hiding somewhere that I just haven’t found?

Not in the standard library.

If not, can anyone thing of a reason why it would be left out of STL?

The general idea with algorithms is that they work with iterators, not containers. Containers can be modified, altered, and poked at; iterators cannot. Therefore, you know that, after executing an algorithm, it has not altered the container itself, only potentially the container’s contents.

Is there perhaps a more full featured set library in boost?

Boost.Range does this. Granted, Boost.Range does more than this. It’s algorithms don’t take “containers”; they take iterator ranges, which STL containers happen to satisfy the conditions for. They also have lazy evaluation, which can be nice for performance.