Re: design problem...
aaragon wrote:
[...]I'm using policy-based design. The idea is to have a Class that
stores elements of Class2 in different ways (arrays in stack memory,
arrays in heap memory, using the std::vector and so on).
Wait a second: all these three have in common that they store elements in
contiguous storage. If you can guarantee that, things become a bit more
simple, otherwise you will need further indirection. Since the principle
remains the same, I'll assume contiguous storage for simplicity though.
I would like the user to customize the creation of a class with Class2
and StoragePolicy like this
typedef Class<Class2,HeapStorage> class_;
A way to accomplish this may be
template <
class T,
class Class2,
template <class> class StoragePolicy = Storage2 >
class Population : public StoragePolicy<Class2>
{
T* pointee_; // points to actual storage
...
};
However, in this way the user cannot customize in the way given before
but it has to introduce the type that pointee_ points to (and this is
not good because the design should know what pointee_ points to from
the StoragePolicy).
I don't understand here how the class Class2 from above now gets another
class T here. Shouldn't it be just one element type and one storage policy?
Therefore, take 2 becomes:
template <class T>
class StoragePolicy
{
void create(size_t s);
};
template <class T>
struct Storage1
{
void create(size_t s) { storage_ = std::vector<T>(s);}
protected:
std::vector<T> storage_;
~StdVectorStorage() {}
};
<
class Class2,
template <class> class StoragePolicy = Storage1 >
class Class : public StoragePolicy<Class2>
{
// this->storage_ (the storage_ is inherited from one of the
StoragePolicy classes)
...
};
This is the way I thought it better to solve this problem. Now, the
questions I have are:
1. Is there a better solution for this? More elegant?
I wouldn't necessarily use protected data. Also, I would for the sake of
users document the StoragePolicy template better, so they know what a
concrete policy needs to provide. In particular, that is:
- a create function taking the required size
- a container called 'storage_'
Maybe with better performance?
There is nothing here that hinders performance. Probably most functions will
only forward to those of the storage implementation, so that's not
critical. You should measure/profile first anyway.
2. In this way, I can't declare the function create() static because I
have a variable in the PolicyClass, right? I tried but I have a
linkage error in the compilation.
In short, it can't be static. For the why, please read the FAQ and the
differences between (free, unbound) function and memberfunctions.
3. Now the key issue. Once I have many of these storage policy
classes, I don't know what to do to traverse the containers. It would
be nice to have a random access iterator that traverses the container
as with the standard library. How do I accomplish this?
That one's simple, you add the requirement that the policy also has a nested
type (or typedef) called iterator and two functions returning iterators to
the beginning and end of the sequence. Spice up with const_iterators or
reverse_iterators as you like and need.
Funnily, I just did something similar. I implemented a string type that
either has a constant maximal size or a variable size with 8/16/32 bit
size_type. There also was one baseclass that only did the allocation, it
had roughly this interface:
struct allocator: noncopyable
{
allocator();
~allocator();
void alloc( size_t);
char* data();
char const* data() const;
};
It performed size checking in alloc() and managed either a dynamic array or
had a static array. This was used as a policy and everything else was
implemented on top of it. These also can't be static, because internally it
does have data to work with so it needs an object.
Uli
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]