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