[List / Vector]: Need some foundation advice

Question

I would like some advice on how I can solve an interesting problem I have.

The problem is to have two storage containers, of which the user selects which one to use for the remainder of the program (edit: at runtime). The two containers are Vector and List and store an object type we are to define. These two containers can be accessed using any means you desire (pop/[i]/...) How would you go about solving this problem?

Below is my best (almost working) solution, but I would really like to see what solutions more skilled C++ professionals have. As previously stated, I am really interested if I am taking the right approach. I have more than typical free time this semester and I intend to use it to really improve my c++ abilities. Thanks for your feedback.

Version 1

To start, I have a boolean flag,

bool using_vector = true;   // what storage container was selected?

Second comes my two containers,

list<Question> q_llist;
vector<Question> q_vec;

Third my implementations for accessing the containers, (still haven't figured out how make get_question() work in a graceful way, and I am not fond of the current route I am taking at the moment)

const Question& get_question(){
    Question q = (using_vector) ?
            q_vec.back() : q_llist.back();

    (using_vector) ?
            q_vec.pop_back() : q_llist.pop_back();

    return q;
}


int questions_size(){
    return (using_vector) ?
            q_vec.size() : q_llist.size();
}


void push_back_question(Question& q){
    if(using_vector){
        q_vec.push_back(q);
    }else{
        q_llist.push_back(q);
    }
}

Version 2

Note: Please use the tag "#v2" when referencing.

I decided to attempt the polymorphism approach. How does this implementation look?

/**
 * using polymorphism to implement a parent class "Container"
 * depending on user selection, reference C_Vec or C_List
 */
class Container {
protected:
    list<Question> qlist;
    vector<Question> qvec;

public:
    void push_back(Question& q){/** do nothing */}
    void pop_back(){/** do nothing */}
    int size(){/** do nothing */}
    Question& back(){/** do nothing */}
};

class C_Vec: public Container{
public:
    void push_back(Question& q){qvec.push_back(q);}
    void pop_back(){qvec.pop_back();}
    int size(){return qvec.size();}
    Question& back(){return qvec.back();}
};

class C_List: public Container{
public:
    void push_back(Question& q){qlist.push_back(q);}
    void pop_back(){qlist.pop_back();}
    int size(){return qlist.size();}
    Question& back(){return qlist.back();}
};

int main(){

    Container *store;
    char user_in;

    cout << "Before we begin please select a storage container:" << endl
         << "a) Linked List" << endl
         << "b) Vector" << endl << ':';

    cin >> user_in;

    if(tolower(user_in) == 'a'){
        C_List l;
        store = &l;
    }else{
        C_Vec v;
        store = &v;
    }
}

Answer 1

You have several options. If you need to decide at runtime which container to use, polymorphism (inheritance) might work well.

#include <vector>
#include <list>
#include <memory>

struct Question {};

// runtime
struct Question_container {
  virtual const Question& get_question() = 0;
  virtual int questions_size() = 0;
  virtual void push_back(const Question&) = 0;
  virtual ~Question_container() = default;
};

struct Vector_question_container : Question_container {
  const Question& get_question() override { return qv.back(); }
  int questions_size() override { return qv.size(); }
  void push_back(const Question& q) override { qv.push_back(q); }
private:
  std::vector<Question> qv;
};

struct List_question_container : Question_container {
  const Question& get_question() override { return qv.back(); }
  int questions_size() override { return qv.size(); }
  void push_back(const Question& q) override { qv.push_back(q); }
private:
  std::list<Question> qv;
};

int main()
{
  // some how figure out which container to use
  std::unique_ptr<Question_container> qc{new Vector_question_container()};
}

If you can make the choice at compile-time, you could make the underlying sequence a template (or even template template) argument.

// CompileTime
template<typename Sequence>
struct Question_container_c {
  const Question& get_question() { return s.back(); }
  int questions_size() { return s.size(); }
  void push_back(const Question& q) { s.push_back(q); }
private:
  Sequence s;
};

int main()
{
  Question_container_c<std::list<Question>> qlc;
  Question_container_c<std::vector<Question>> qvc;

  return 0;
}

Although you could also just make your algorithm work on iterators and leave the choice of the container to the user. This might be hard for some methods such as your push_back, but it doesn't actually do anything else then the normal push_back already provided.

Answer 2

To complement @pmr's answer, if you want to do it in an idiomatic way, you can create an adapter interface:

class IContainer {
public:
    virtual ~IContainer() {}
    virtual void push_back(const Question & q) = 0;
    virtual void pop_back() = 0;
    virtual const Question & back() const = 0;
    virtual unsigned int size() const = 0;
};

And a generic implementation:

template <class T>
class Container: public IContainer {
private:
    T m_container;

public:
    virtual void push_back(const Question & q) {
        m_container.push_back(q);
    }

    virtual void pop_back() {
        m_container.pop_back();
    }

    virtual const Question & back() const {
        return m_container.back();
    }

    virtual unsigned int size() const {
        return m_container.size();
    }
};

So you can do this:

std::unique_ptr<IContainer> pctr;
if (choice) {
    pctr.reset(new Container<std::vector<Question>>);
}
else {
    pctr.reset(new Container<std::list<Question>>);
}
std::cout << pctr->size();

Answer 3

I suppose the best way for your approach is to use iterators instead. Iterators are invented as a container abstraction in mind (sure thing, you can't abstract by 100% due different behavior of containers but anyway you have a solution better than nothing).