Re: [boost] [Containers] Should flat_* expose implementation vector?

Subject: Re: [boost] [Containers] Should flat_* expose implementation vector?
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-08-08 10:41:39

on Fri Aug 05 2011, "Phil Endecott" <spam_from_boost_dev-AT-chezphil.org> wrote:

> Dear All,
>
> Should Ion's proposed flat_set, flat_map etc. expose the underlying
> vector that they use as their implementation?
>
> Pros: it lets the user efficiently load and save the content, and
> implement algorithms that cannot be done via the flat_* interface.
>
> Cons: it lets the user break the invariants.
>
> Const access to the impl is another possibility.
>
> Related to that: could the implementation type be a template
> parameter?  Example: could one implement a flat_set on top of a
> stable_vector?  (Is that useful?)  

One way I've dealt with this sort of thing in the past is to allow the
user to get an intrusive and dangerous interface initially, and then
throw it away later leaving only an invariant-preserving interface.

Obviously you can't do that with a single class.

> And/or: should flat_* actually be adaptors that take a reference to
> their underlying implementation?

I'm not sure that's a win if you have move semantics.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com