Re: [boost] [move][container] Review Request (new versions of Boost.Move and Boost.Container in sandbox and vault)

Subject: Re: [boost] [move][container] Review Request (new versions of Boost.Move and Boost.Container in sandbox and vault)
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2009-08-25 11:20:33

On 8/24/09, Jeffrey Hellrung <jhellrung_at_[hidden]> wrote:
> Ion Gaztañaga wrote:
>> Gottlob Frege escribió:
>>> Any thoughts (from anyone?) on my comments about making flat_map's
>>> iterators
>>> stable?  Then it would be a complete replacement to std::map.
>>> Tony
>>
>> Making flat_xxx a template adaptor (like stack or similar) and using
>> stable_vector as the underlying type would make flat_stable_vector a
>> replacement for std::map.
>>
>> Best,
>>
>> Ion
>
> I would prefer it as is, but I haven't had a need for iterator
> stability.  I thought the point of a flat_map/flat_set was to be an
> as-lightweight-as-possible generic associative container, but still with
> reasonable (O(log n)) lookup time.
>

I think the point was to have a map that could be shared in
interprocess memory. At least that was the original idea. But that
could now be done with a std::map if we had stateful allocators.

> Perhaps a policy-based approach is possible, or an entirely separate
> class, e.g., stable_flat_xxx?
>

If you had a stable one, which was this more maplike, should it be
called flat_map, and the unstable on be renamed? To sorted_vector or
something?

By either implementing stableness or renaming, I'm trying to minimize
potential misuse.  I do understand that stableness isn't the most
often used feature, but it might catch some by surprise. Probably not
the developer that puts in the flat_map, but by the next one that
comes by to use it.

Tony

> - Jeff
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>