On Mar 27, 2012 11:21 AM, "Robert Jones" <robertgbjones@gmail.com> wrote:
>
> On Wed, Nov 23, 2011 at 6:50 PM, Nathan Ridge <zeratul976@hotmail.com> 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