Re: design problem...
Ulrich Eckhardt wrote:
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.
Well, thanks to the help of another post in the newsgroup, I decided to
do it as follows:
template
<
class T,
template <class> class Sequence = std::vector
class Population
{
Sequence<T> storage_;
...
public:
};
I guess this is simple and elegant. Also, since I'm using template
template parameters, the user does not have to put the element to store
twice. That is:
typedef Population<T,std::vector> pop
instead of
typedef Population<T,std::vector<T> > pop
Now I need to figure out a way to change the name of std::vector to a
more user friendly name (as StdVector for example). The idea is that
the user will be able to select from many different contiguous storage
options (vector, list, array (I need to write the wrapper for this
one), etc).
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?
Yeah! Figured this out after the implementation above... =)
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_'
No more protected data! =)
Also, I will be using doxygen to documentation purposes....
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.
measure/profile? Well, I thought about using gprof for the program,
even though this will give me the performance overall. I will try to
find also a way to measure some parts of the code with a timing
function or something like that. I guess there are system functions
that get the current time (let's say before a loop starts) and then I
can measure it again after a while (end of the loop).
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.
Can you give me the link to the FAQ?
{ please follow the link in the moderation server banner below
for some useful information (a link to FAQ is also there). -mod }
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.
Should I use a wrapper around the std containers with this? and then
create the policy in this fashion? Let's say,
template <typename T>
struct StdVector
{
typedef std::vector<T>::iterator iterator;
....
}
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.
This looks nice. How do you give the option between static and dynamic
storage in this policy?
Uli
Thanks a lot Uli for your answers. =)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]