stl container as template argument

let's say I have a function like this:

Code:

---

template<typename ContainerT, typename ValueT>
void foo(const ContainerT<ValueT>& c)
{
  typedef ContainerT<ValueT> type;
  for (type::iterator it = c.begin(); it != c.end(); ++it)
  {
    // do some stuff
  }
}

---

and I would call it as follows:

Code:

---

std::vector<int> intVector;
std::list<std::string> stringList;

foo(intVector);
foo(stringList);

---

obviously this will not compile, because the compiler has no way of knowing that ContainerT is a template type.

is there any way to make something like this work?

Make it

Code:

---

template<typename ContainerT>
void foo(const ContainerT& c)

---

Now, typical containers expose public typedefs within that you can grab for the value type, etc.
I believe typename ContainerT::value_type should do the trick for replacing ValueT.

yes, that will work with standard containers, but I was hoping there was a way to separate the container from its value type in the template parameters, for other potential uses. I can foresee a situation where the parameter would be something other than a container, and the function would do something other than iterate, and you would need to know what ValueT is, without depending on a specific interface.

If you want that, then you will have to make an extra layer of redirection. There is a way to detect if there is a typedef of a specific type or not and depending on that fact, take an action.
You should make sure that your containers contain a value_type typedef to make it work with this function, too.

Unfortunately, standard containers take an undefined amount of template parameters, making this approach tricky. You might be able to pull it off using varadic templates, though.

Fundamentally the trouble stems from putting the ContainerT type into the equation in the first place. Move the iterators OUTSIDE this function, forcing the caller to pass the beginning and ending iterators explicitly instead of obtaining them within your template. Not only do you gain freedom from needing to know the container type, you gain the ability to support things that don't have begin() and end() functions, and things which aren't even classes at all (like bare pointers).

In fact I'd just chuck the whole thing and use std::for_each.

It's possible that you want a templated template type:

Code:

---

template<template <class> class ContainerT, class ValueT>

---

Yes that's valid syntax, I use essentially that in my policy based renderer.

Quote:

---

Originally Posted by iMalc

Code:

---

template<template <class> class ContainerT, class ValueT>

---

---

that seems to work ok, but when I replace the keyword "class" with "typename" I get the error "expected 'class' before 'ContainerT'

I'm using G++ 4.6.1 on Fedora 15. is this a bug in G++, or is it actually mandatory to use "class" in this case? I've had situations where the reverse was not allowed, but I've never seen a case where you couldn't use the "typename" keyword in place of "class."

As expected, this does not compile properly:

Code:

---

#include <vector>

template<template<typename> class ContainerT, typename ValueT>
void foo(const ContainerT<ValueT>& c)
{
  typedef ContainerT<ValueT> type;
  for (typename type::iterator it = c.begin(); it != c.end(); ++it)
  {
    // do some stuff
  }
}

int main() { std::vector<int> v; foo(v); }

---

(Btw, you forgot the red part.)

I was able to get it to compile with the following:

Code:

---

#include <vector>

template<template<typename, typename> class ContainerT, typename ValueT>
void foo(const ContainerT<ValueT, std::allocator<ValueT>>& c)
{
  typedef ContainerT<ValueT, std::allocator<ValueT>> type;
  for (auto it = c.begin(); it != c.end(); ++it)
  {
    // do some stuff
  }
}


int main() { std::vector<int> v; foo(v); }

---

But this just shows how unreliable this method is, and how it should not be used.

I've decided to abandon my research into this. it may be possible, but the work involved to make a portable, universal solution appears to be quite unreasonable.