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

Subject: Re: [boost] [Containers] Should flat_* expose implementation vector?
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2011-08-06 08:56:31

El 06/08/2011 2:32, Phil Endecott escribió:
> 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.

Another possibility is to have a constructor an implementation (which 
should be guaranteed to be ordered and unique (for flat_(multi)set) 
taking a implementation as rvalue. Another impl_t extract() function 
that move returns (or additionally as in some cases (like loops) is more 
efficient to avoid new object creation, via swapping: void 
exchange(impl_t &imp)).

In debug mode we could check ordering when constructing from an 
implementation.

 > Const access to the impl is another possibility.

This is easy and useful for passing the vector to other functions that 
don't need any ordering.

> 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?) And/or: should flat_* actually be adaptors that take a
> reference to their underlying implementation?

The problem is that flat_xxx take advantage of already implemented move 
semantics (insertions, etc.) from ::boost::container::vector. 
stable_vector has the same interface so it would be easy. The problem is 
to define the Concept (in post C++0x terms) flat_xxx::implementation 
should be based on.

Best,

Ion