Re: [Boost-users] [Range] insert algorithm fails if target is a map

Subject: Re: [Boost-users] [Range] insert algorithm fails if target is a map
From: Neil Groves (neil_at_[hidden])
Date: 2012-09-11 00:41:43

On Mar 27, 2012 11:21 AM, "Robert Jones" <robertgbjones_at_[hidden]> wrote:
>
> On Wed, Nov 23, 2011 at 6:50 PM, Nathan Ridge <zeratul976_at_[hidden]>
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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users