11

I'm attempting to create a generic container type to provide a single common interface, as well as hide the internal containers I'm using as they are subject to change.

Basically I have plugins that return collections of items and I don't wish the plugins to be aware of the type of container my code is using.

Can anyone point me in a better direction then the example code below?

template<class C, typename I> class Container { public: //... void push(const I& item) { if(typeid(C) == typeid(std::priority_queue<I>)) { std::priority_queue<I>* container = (std::priority_queue<I>*)&_container; container->push(item); } if(typeid(C) == typeid(std::list<I>)) { std::list<I>* container = (std::list<I>*)&_container; container->push_back(item); } else { //error! } }; private: C _container; //... }

Thanks

Improve this question
5
  • 4
    I can. Don't do that. Spend your time on designing your app so it uses statically typed containers. Commented Dec 31, 2010 at 7:07
  • 1
    I can point you in a better direction, sure: don't attempt to do this. Seriously. It won't gain you anything. Voice of experience speaking here. Commented Dec 31, 2010 at 7:08
  • 8
    Why the downvote here? It's a perfectly legitimate question. Even if the answer is "don't do it this way", it was still a valid question. Commented Dec 31, 2010 at 7:13
  • 1
    I don't understand. I have an interface that is implemented by my plugins that requires a std::list to be returned. At a later date some requirement comes along to have these elements ordered for example. By hiding the type of container returned i will allow myself the flexibility to change without breaking existing plugins. Am i missing something here? Commented Dec 31, 2010 at 7:15
  • 4
    Just require that a sequence container is used; then you can use list, deque, or vector (or any other nonstandard container that meets the sequence container requirements) without any special handling at all. The entire point of the container concepts is that you can easily write code that will work with any container that meets the requirements. (Yes, this means you won't be able to use non-containers like priority_queue directly, but it's highly unusual to need to do that anyway.) Commented Dec 31, 2010 at 7:19

3 Answers 3

Reset to default
7

I have plugins that return collections of items and I don't wish the plugins to be aware of the type of container my code is using.

Have your plugins provide begin and end iterators into their collections of items and then consume the range as you see fit.

The greatest advantage of iterators is that they allow complete decoupling of how the data is stored (the container) from how the data is used (the algorithm; in your case, your application code that consumes the plugin data).

This way, you don't have to care how the plugins store their data and the plugins don't have to care what you do with their data once they give it to you.

Improve this answer
Sign up to request clarification or add additional context in comments.

8 Comments

@user: I don't understand; an iterator interface has no more concurrency issues than a container interface: either lock the container while you are iterating over it or make a copy of the container to iterate over.
@BretKuhns: I think the fact that STL iterators are duck-typed is not the issue here. Suppose you define vector<int> x; at file scope and a later function refers to x.begin() or x.end(): that function (the "consumer") will need to be recompiled if the definition of x is changed to list<int> x;. Usually this isn't a big deal -- unless you're building a plugin system which needs to consume (iterate over) as-yet-unknown container types. In my comment, I was looking for a way to avoid having to recompile the consumer in this situation.
@j_random_hacker, OK I see your point now. You're right, runtime dispatching would be the solution to avoid recompiling.
@BretKuhns: Today I randomly came across this more in-depth treatment of what I'm suggesting, in case you're interested: artima.com/cppsource/type_erasure.html. Good to know I'm not crazy :)
@j_random_hacker that was a great read, and surprisingly relevant to something I've been cooking up recently. Thanks for the follow-up!
|
0

You know, when you wrote "common interface", I was sure you were going to show something Java style with an abstract class and subclasses that wrap standard containers. I was surprised to see a bunch of typeid calls...

But then, why do you want to do this? Most containers share a common interface, and with the power of SFINAE, you don't even have to write special code! Just use templates and call the method directly.

EDIT: Forgot that standard containers have no virtual methods and therefore, cannot be dynamic_casted.

Improve this answer

Comments

0

Start with a class as above, expose minimal interface needed by your plugins. Then implement it in terms of the container you are going to use. This is called container adapter and it is how std::stack is implemented.

If you really need adapter for more then one STL container go with template, have a look at std::stack, it will show how to do that.

Don't switch on typeid, why would you want that?

BTW, go with what James suggests unless there is a need to expose container itself.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.