views:

219

answers:

2

I've a custom container which is implemented in two different ways, but with a single interface. some thing like this.

    class Vector 
    {
       virtual Iterator begin() = 0;
       virtual Iterator end () = 0 ;

    ... // some more functions.
    } ;

    class VectorImplA : public Vector
    {
       Iterator begin() { return m_data.begin() ; }
       Iterator end () { return m_data.end() ; }
    private:
       SomeFloatContainer m_data ;
    } ;

    class VectorImplB : public Vector
    {
       Iterator begin() { return m_data.end() ; }
       Iterator end() ; { return m_data.end() ; }


    private:
        std::vector <float> m_data ;

    } ;

What I need is a unified interface to Iterator, so that I'can use it in base class. Any Ideas ?

A: 

A possibility is to use a template class for your container, with the private data-container as parameter. This way, the iterator can be defined in the class independent of the data-container.
I'm just not sure whether this is "unified" enough for what you need.

stefaanv
+2  A: 

I've run into exactly this problem myself before. While there are ways to solve your problem, you most likely should let go of the idea of a vector base class. What you probably should do instead, is mimic the way the c++ STL container are designed.

The STL consists of concepts rather than base classes. An std::vector is a model of the Container concept, but does not inherit from a Container base class. A concept is a set of requirements that any model of the concept should adhere to. See this page from SGI for the requirements for Container for example.

The requirements for Container state for example that you should typedef the type of the contents of the container as value_type, and typedef iterators as iterator and const_iterator. Furthermore, you should define begin() and end() functions returning iterators, and so on.

You'll then need to change functions that operate on your Vector base class to instead operate on any class that adheres to the requirements imposed by the concept. This can be done by making the functions templated. You don't necessarily have to stick to the concepts used by the STL, you might as well cook up your own. Sticking to the concepts as they are defined in the STL has the additional benefit that the STL algorithms (std::sort for example) can operate on your containers.

Quick example:

class VectorImplA
{
public:
    typedef VectorImplAIterator iterator;

    iterator begin();
    iterator end();
};

class VectorImplB
{
public:
    typedef VectorImplBIterator iterator;

    iterator begin();
    iterator end();
};

template <typename VectorConcept>
void doSomeOperations(VectorConcept &container)
{
    VectorConcept::iterator it;
    it = container.begin();
}

int main()
{
    VectorImplA vecA;
    VectorImplB vecB;
    doSomeOperations(vecA); // Compiles!
    doSomeOperations(vecB); // Compiles as well!
}

As a bonus, to answer the original question, consider the following design (I wouldn't go this way though!):

struct IteratorBase
{
    virtual void next() = 0;
};

struct IteratorA : IteratorBase
{
    void next() {};
};

struct IteratorB : IteratorBase
{
    void next() {};
};

class Iterator
{
    IteratorBase *d_base;
public:
    void next() { d_base->next(); }
};
TC
+1 though I would definitely NOT use a `next` operation, better to stick to the usual conventions for interoperability with STL.
Matthieu M.
Thanks for the answers. I've already implemented #1, which was outlined above. The problem with that is I cannot have runtime polymorphism. i.e., derive VectorImplA and VectorImplB from base class Vector and use Vector* for operating on the derived classes. Am I correct ?
Surya