|
Boost : |
From: Phil Bouchard (philippe_at_[hidden])
Date: 2008-08-14 06:50:03
"Gordon Woodhull" <gordon_at_[hidden]> wrote in message
news:A671761D-B76D-4C0C-86A6-592023FCFABC_at_woodhull.com...
[...]
> I think that the principles of ownership and the lifetime management
> system you are proposing could probably be applied to systems of
> intrusive containers, more quickly than a change to the c++ standard
> (perhaps via the metagraph library I'm working on ;).
[...]
Let's put it this way. All new "unordered" and multiset containers could
easily be implemented as:
1) superc1st<double, list, vector> s1;
2) superc2nd<string, double, map, vector> s2;
3) superc2nd<string, double, map, map> s3;
Where (explicit specializations for sake of example and please disregard
missing "typename"s):
1)
template <>
class superc1st<double, list, vector> : public _list<0, void, double>,
_vector<1, void, double> {...};
Here are examples of its usage:
s1.push_back(5.7);
s2[0] = 5.8;
2)
template <>
class superc2nd<string, double, map, vector> : public _map<0, string,
double>::base, _vector<1, string, double>::base {...};
This one can be accessed as such:
s2["Height"] = 6.3; // <-- O(log n)
s2[10] = 5.9; // <-- O(1)
3)
template <>
class superc2nd<string, double, map, map> : public _map<0, string,
double>::base, _map<1, string, double>::base {...};
To access 3) we could add indexed types we can cast the container to:
s3.get<0>()["Age"] = 31;
The underscored containers will be defined as:
template <int I, typename T, typename U>
struct _map : std::map<T, U>
{
typedef std::map<T, U> base;
base & get<I>() { return * this; } // we can't specialize functions
but you get the idea
};
And:
template <int I, typename T, typename U>
struct _vector : std::vector<U>
{
typedef std::vector<U> base;
...
};
...
I think this is very easy to implement, cleaner and much more flexible (can
use vectors and no container can be forgotten). My brain kernel example
already needs something similar extensively...
Thanks,
-Phil
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk