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