[Range] insert algorithm fails if target is a map
The title says it all really. The failure occurs because the insert algorithm expects the container to provide a 3-arg insert of the form container.insert( position, begin, end ); whereas map's, multimap's and set's insert method only takes two arguments... map.insert( begin, end ); Is this limitation by design? It would be easy to provide specialisations for maps, mmaps and sets, but that would not be a completely general solution. - Rob.
The title says it all really. The failure occurs because the insert algorithm expects the container to provide a 3-arg insert of the form
container.insert( position, begin, end );
whereas map's, multimap's and set's insert method only takes two arguments...
map.insert( begin, end );
Is this limitation by design? It would be easy to provide specialisations for maps, mmaps and sets, but that would not be a completely general solution.
I think what we really need is a second insert algorithm. The one we have right now: Container& insert(Container& target, typename Container::iterator before, const SinglePassRange& from); should call target.insert(before, begin, end), and only work for sequence containers, while a new one: Container& insert(Container& target, const SinglePassRange& from); should call target.insert(begin, end), and only work for associative containers (or any other container where you have no control over the position it's inserted at, e.g. a hypothetical sorted vector). I don't think it makes sense to try and get the first one to work for associative containers, because the "before" parameter is meaningless for those. Regards, Nate
On Wed, Nov 23, 2011 at 6:50 PM, Nathan Ridge
The title says it all really. The failure occurs because the insert algorithm expects the container to provide a 3-arg insert of the form
container.insert( position, begin, end );
whereas map's, multimap's and set's insert method only takes two arguments...
map.insert( begin, end );
Is this limitation by design? It would be easy to provide specialisations for maps, mmaps and sets, but that would not be a completely general solution.
I think what we really need is a second insert algorithm.
The one we have right now:
Container& insert(Container& target, typename Container::iterator before, const SinglePassRange& from);
should call target.insert(before, begin, end), and only work for sequence containers,
while a new one:
Container& insert(Container& target, const SinglePassRange& from);
should call target.insert(begin, end), and only work for associative containers (or any other container where you have no control over the position it's inserted at, e.g. a hypothetical sorted vector).
I don't think it makes sense to try and get the first one to work for associative containers, because the "before" parameter is meaningless for those.
Darn.. bumped into this one again! Neil, is there any likelihood of any action on this one? I think Nate's suggestion would be ok, although it would introduce an overload without some SFINAE protection. Thx, Rob.
On Mar 27, 2012 11:21 AM, "Robert Jones"
On Wed, Nov 23, 2011 at 6:50 PM, Nathan Ridge
wrote:
The title says it all really. The failure occurs because the insert algorithm expects the container to provide a 3-arg insert of the form
container.insert( position, begin, end );
whereas map's, multimap's and set's insert method only takes two
arguments...
map.insert( begin, end );
Is this limitation by design? It would be easy to provide
No, this limitation is due to my intellectual shortcomings and inadequacy - sorry. I'll ensure this is resolved.
specialisations for maps, mmaps and sets, but that would not be a completely general solution.
It seems, to me that we have a design pattern for this problem. A trait can be defined and we can define the examples above as having the trait. The implementation can then use tag dispatch and/or enable_if.
I think what we really need is a second insert algorithm.
The one we have right now:
Container& insert(Container& target, typename Container::iterator before, const SinglePassRange& from);
should call target.insert(before, begin, end), and only work for sequence containers,
I think it should simply ignore the 'before' hint to be consistent with single element insertion behaviour of containers.
while a new one:
Container& insert(Container& target, const SinglePassRange& from);
should call target.insert(begin, end), and only work for associative containers (or any other container where you have no control over the position it's inserted at, e.g. a hypothetical sorted vector).
I don't think it makes sense to try and get the first one to work for associative containers, because the "before" parameter is meaningless for those.
I disagree that it doesn't make sense to make this work. The standard had a single element insertion that takes a position as a hint. I find the treatment of insertion by single element to be jarringly inconsistent. I will add support this case.
Darn.. bumped into this one again! Neil, is there any likelihood of any action on this one? I think Nate's suggestion would be ok, although it would introduce an overload without some SFINAE protection.
Consider this finally being bumped!
Thx, Rob.
Neil Groves
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (3)
-
Nathan Ridge -
Neil Groves -
Robert Jones