|
Boost : |
Subject: [boost] [shared] : container : any interest
From: Ingo.Loehken_at_[hidden]
Date: 2009-03-05 08:42:27
Hi,
as a consequence of my daily work in COM design, it revealed, that most
often there are
only views into existing containers required, so copies can be delayed,
until container
invariants are viloated - elements are already shared, as they reference
pointers with
embedded reference counts.
Thus, the design fulfills the following objectives :
+ Every existing container can be adopted to be a shareable container.
Shareable
means, concurrent read and write access to elements. Container invariant
methods, such
like insert for sorted associative containers, trigger a copy of the
container.
+ Iterators are managed. This guarantees valid iterators, even if the
underlying container
is copied, because of a container invariant modifying operation.
+ The existing concepts for containers are mapped to support shared
containers. This avoids
any redundant code and provides maximum flexibility in combining
concepts via base class
chaining.
+ Every shared container behaves simply like its stl or boost counterpart
(except unsorted,
because of a current unsolved issue regarding the iterators in buckets,
requiring a second
layer of managed iterators - imho inefficient), so that usage is as
simple as with original
containers.
A brief example
using boost::shared;
set<int> x, y = x; // y is attached to the same container as x, no copy
x.insert(3); // y gets detached from x, because set invariant
(sort order) is modified
list<int> x;
x.push_back(3);
list<int> y = x;
y.front() = 8; // also modifies the value in x
list<int>::const_iterator cit(x.begin()); // attach iterator to
container shared by x and y
y.pop_back(); // detaches y from container
shared with x (container invariant)
std::cout << *cit << std::endl; // output : 8 (iterator still
valid)
Is there any interest for boost, to support such a library or is the
number of use
cases to small to introduce something like that ?
Thx, ILo.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk