I have legacy code where a similar method is used to cycle through a sequential container (vector in this example. Some implementations use other kinds of containers). So I factored it out into a template so I could reuse the same piece of code for any container type.
template<template<class, class> class TContainer, class TObject>
class cycle
{
public:
explicit cycle( TContainer<TObject, std::allocator<TObject>> & container )
: mContainer( container ), index(0) {}
TObject getNext(int numObjectsToCycle)
{ return mContainer[index++ % numObjectsToCycle]; }
private:
TContainer<TObject, std::allocator<TObject>> & mContainer;
int index;
};
Then my class has a cycler to cycle through my variable numbers.
class myClass
{
std::vector<int> numbers;
public:
cycle<vector, int> cycler;
// Is it safe to pass numbers since it is declared first??
myClass() : cycler(numbers) {}
};
Then, I use the code like below.:
myObject.cycler.getNext(size);
Is it a good programming practice to pass the vector "numbers" to cycler? Is there a better way of implementing my template?
The code really is to be able to infinitely loop through objects. My class is invoked from external code that just calls a member method, and I want to be able to just call getNext() so I wouldn't have to use an index.
In the standard library another "pattern" exists and it's the iterator pattern. Basically every container type implements begin and end which returns, respectively, the iterator to the first element and the past-the-end element (which is always guaranteed to exists).
This works for every container type, from std::vector to std::array including C-style arrays with std::begin and std::end. If you want to loop in a generic container you can do, for example:
template<typename Container>
void cicle(Container const& c) {
for (auto const& i : c) {
// …
}
}
or, to better visualize the pattern:
template<typename Container>
void cicle(Container const& c) {
for (auto it = std::begin(c); it != std::end(c); ++it) {
// …
}
}
Live demo
Related
I am trying to write wrapper classes around std::list and std::vector with their own iterators so that I can then write a superclass for both of those classes and their iterators. My current code looks basically like this:
template <class T>
class MyCollection
{
//Not sure how to write this class.
public:
class iterator
{
//Not sure how to write this class either
//I think MyVector::iterator and MyList::iterator
//should inherit from this class
};
};
template<class T>
class MyVector : public MyCollection<T>
{
private:
vector<T> data;
public:
MyVector(int * start, int * end) : data(start, end) {}
class iterator : vector<T>::iterator
{
iterator(typename vector<T>::iterator i) : vector<T>::iterator(i) {}
};
iterator begin() { return iterator(data.begin()); }
};
template<class T>
class MyList : public MyCollection<T>
{
private:
list<T> data;
public:
Mylist(int * start, int * end) : data(start, end) {}
class iterator : list<T>::iterator
{
iterator(typename list<T>::iterator i) : list<T>::iterator(i) {}
};
iterator begin() { return iterator(data.begin()); }
};
I would like to be able to have some code that does this:
int ints[] = {1,2,3,4,5};
MyList<int> l(ints, ints+5);
MyCollection<int> * c = &l;
MyCollection<int>::iterator i = c->begin();
and after that code executes, I would like to be able to iterate through the MyList l using i.
I feel like there needs to be a virtual begin() member function in MyCollection, but I cannot figure out what the proper return type should be.
Is what I'm trying to do even possible? It's entirely possible that the current organization of my code is totally wrong. That's just what I've tried. My goal is just to get it so that the example driver code above can work, so an answer may involve a total restructuring of the code. I'm really just looking for suggestions. I don't need a complete answer.
I wouldn't write a wrapper for std::vector and std::list in this case for the sole purpose of using std::list or std::vector uniformly. You don't need to.
What you want is to use type erasure in a similar way to what you can find here.
The whole idea for you would be to implement only MyCollection<T> with a type erased iterator and use type erased iterator for traversing any of the collections. No need for MyList<T> or MyVector<T>.
MyCollection::begin should return a MyCollection::iterator, by convention. Therefore MyVector::begin() should return something that's at least a MyCollection::iterator, too. It may be a more derived type, though.
In your case, MyVector::begin() returns a MyVector::iterator, which is not derived from MyCollection::iterator. That's why it fails.
I have multiple controls organized like this:
deque<wxTextCtrl*> dequeEdit;
deque<wxStaticText*> dequeText;
deque<wxComboBox*> dequeCombo;
All these controls inherit from wxWindow which has mathod Show. I'd like to show (or hide) whole deque at once, without the need of multiple methods for each deque. How could it be done?
I was thinking about making deque of wxWindow for each control, so I could write method
ShowDeque(deque<wxWindow*> deque)
so showing would be easy, but on the other hand, if I'd like to work with e.g. combobox, I'd have to type it back to wxComboBox.
Are there any other possibilites? Thanks.
Use:
for_each(dequeEdit.begin(), dequeEdit.end(), mem_fun(&wxWindow::Show));
Same for any other deques.
Or encapsulate in one function:
template <class Deque>
void showAll(const Deque& dequeObj)
{
using namespace std;
for_each(dequeObj.begin(), dequeObj.end(), mem_fun(&wxWindow::Show));
}
showAll(dequeEdit);
std::for_each: http://en.cppreference.com/w/cpp/algorithm/for_each
std::mem_fun: http://en.cppreference.com/w/cpp/utility/functional/mem_fn
If it's a simple method make it a template:
template <typename WxT>
void ShowDeque(std::deque<WxT*> &d) { ... }
or better, use iterators to abstract out the container type:
template <typename WxIter>
void ShowDeque(WxIter begin, WxIter end) { ... }
or better yet use the standard facilities (Piotr beat me to that one while I was typing!)
You can use a function template.
template <typename T>
void show_all(const std::deque<T*>& d) {
for (typename std::deque<T*>::iterator it=d.begin(); it!=d.end(); ++it)
(*it)->Show();
}
You can then call it like a normal function.
deque<wxTextCtrl*> dequeEdit;
deque<wxStaticText*> dequeText;
deque<wxComboBox*> dequeCombo;
show_all(dequeEdit);
show_all(dequeText);
show_all(dequeCombo);
With a function template you can even make show_all independent of the container you use by adding an additional template argument.
template <typename C, typename T>
void show_all(const C<T*>& d) {
for (typename C<T*>::iterator it=d.begin(); it!=d.end(); ++it)
(*it)->Show();
}
C can then be any STL container, or even any container which supports the same iterator interface.
I came across this question when looking for how to use inheritance of iterators and deque.
The answer's does not give a complete answer related to inheritance, so I will add following:
Let say you have a class and you want this class to have the ability to have a deque inside, in other words to inherit the ability to control a deque container.
Example :
template<typename ElementType>
class myQueOfElements : public deque<ElementType>
{
ElementType placeholder;
myQueOfElements& operator=(unsigned char* rvalue)
{
unsigned char* ptrToNextElement = (unsigned char*)rvalue;
placeholder = ptrToNextElement; // make sure ElementType has its own assignment operator=
push_back(placeholder); // First element
//TODO: Iterate thru the binary and push_back the fetched elements
return *this;
}
};
// How to use:
myQueOfElements<myElementTypeClass> testQue;
testQue = (unsigned char*)&blob[0]; // address to binary data, will be parsed in the assignment operator=
// make sure it has same structure as the ElementType (myElementTypeClass)
// fetch all myElementTypeClass object(s) from the myQueOfElements
for (auto e : testQue) {
std::string strName = e.Name;
std::out << "Element : " << strName.c_str() << endl;
}
Java has CopyOnWriteArrayList, which enables me to iterate and mutate using 2 different threads simultaneously, without having any external locking.
Do we have any similar thread safety data structure for C++?
There's nothing in the standard library which would support this. Given
the interface to C++ standard containers, I'm not sure it's possible.
You'd have to start with something like:
template <typename T>
class CopyOnWriteVector
{
boost::shared_ptr<std::vector<T> > myData;
void uniqueCopy()
{
myData = boost::shared_ptr<std::vector<T> >( new std::vector<T>( *myData ) );
}
public:
// ...
// for example...
void push_back( T const& newElement )
{
uniqueCopy();
myData->push_back( newElement );
}
// Similar for all other non-const functions.
// const functions just forward, without the call to
uniqueCopy.
};
This doesn't work, however, for functions which return handles to some
internal data: either iterators or references to elements. For
iterators, it would be possible to create an iterator which contains
a shared_ptr to the container it iterates into, e.g.:
template <typename T>
class CopyOnWriteVector
{
// ...
public:
class iterator : public std::random_access_iterator_tag
{
boost::shared_ptr<std::vector<T> > myVector;
typename std::vector<T>::iterator myImpl;
public:
iterator() {} // for convenience...
iterator( boost::shared_ptr<std::vector<T> > const& vector,
typename std::vector<T>::iterator initialValue )
: myVector( vector )
, myImpl( initialValue )
{
}
// All other iterator functions forward directly to myImpl
};
};
The functions which return references are another issue; you can't
replace the reference with a smart reference, or a proxy of any type.
(Note: all of the above code is just off the top of my head, and probably contains significant errors. It's just to give an idea of the direction you might take.)
I'd like to design a class Foo that stores various data of different types and returns iterators over them. It's supposed to be generic, so the user of Foo does not know how the data is stored (Foo could be using std::set or std::vector or whatever).
I'm tempted to write an interface like this:
class Foo {
class FooImpl;
FooImpl* impl_;
public:
const Iterator<std::string>& GetStrings() const;
const Iterator<int>& GetInts() const;
};
where Iterator is something like this (like iterators in .NET):
template<class T>
class Iterator {
public:
const T& Value() const = 0;
bool Done() const = 0;
void Next() = 0;
};
But I know that kind of iterator is not standard in C++, and it's better to use iterators the way the STL does, so you can use the STL algorithms on them.
How can I do that? (Do I need iterator_traits by any chance?)
Do you understand why the STL chose to put iterator implementation details in the header file? JIT frameworks are able to inline across compilation units, but C++ can only inline within a compilation unit. Advancing through a sequence is much faster when inlined, the cost of a function call dominates actually traversing the data structure.
If you really want to hide the implementation details, go ahead. You could make an STL-compatible iterator that implements operator++ and operator!= and operator-> in terms of protected virtual functions, the Next, Done, and Value you've mentioned would be decent names. Just expect to pay for the encapsulation with lower performance.
A c++ class with iterators has to provide at least two functions if they have to work with the std library
iterator begin() //returns an iterator at starting pos
iterator end() //returns an iterator one past end or just invald
The iterator has to overload the increment operators, equals and *
iterator operator++()
iterator operator==()//make sure that an invalid iterator equals end()
T& operator*()
You can use the iterator class to wrap around the iterator of the internal storage to ensure that the user is limited to these methods.
template <typename T> iter
{
iter(T::iterator& intern)
T::value_type& operator*(){return *intern}
iter operator++(){return iter(++intern);}
bool operator==(iter const& other)const{return intern == other.intern;}
}
Where T is the type of your container.(The class is incomplete and I may have mixed something up)
It almost looks like you're trying to create container-independent code, which is not (in general) a good idea, unless you are writing an algorithm which can operate solely with iterators. (See Scott Myers Effective STL Item 2: Beware the illusion of container-independent code)
The problem is that most of the standard containers do not provide overlapping functionality. If you're writing code for a particular container, assume you're writing code for that container. Don't bother trying to make it container-independent.
Use a typedef to return an boost::iterator_range. For example (never mind the names),
class Container
{
typedef std::vector<int> Collection;
public:
typedef boost::iterator_range<Collection::iterator> CollectionRange;
typedef Collection::iterator CollectionIterator;
Range range() const {
return make_iterator_range(collection_.begin(), collection_.end());
}
private:
Collection collection_;
};
The user code will be
Container c;
// ...
FOREACH(int i, c.range()) { //... }
Container::Range r = c.range();
for(Container::iterator j = r.begin(); j!= r.end(); j++) { // ... }
This is not generic, but the same idea can be used with templates.
To fulfill the requirement that the particular container (vector, set, ...) is not mentioned in the header file, and the user will be able to iterate over all strings, is to use the visitor pattern. The downside, of course, is that the user won't be able to use the STL algorithms on the strings.
// foo.h
class StringVisitor {
public:
void accept(const std::string& str) {
std::cout << str << std::endl;
}
};
class Foo {
class Impl;
Impl* impl_;
public:
Foo();
~Foo();
void VisitStrings(StringVisitor v) const;
};
// foo.cc
class Foo::Impl {
typedef std::vector<std::string> StringContainer;
StringContainer str_;
public:
Impl() {
str_.push_back("a");
str_.push_back("b");
}
void VisitStrings(StringVisitor v) const {
for(StringContainer::const_iterator it = str_.begin();
it != str_.end(); ++it){
v.accept(*it);
}
}
};
Foo::Foo() : impl_(new Impl()) {}
Foo::~Foo() {delete impl_;}
void Foo::VisitStrings(StringVisitor v) const {
impl_->VisitStrings(v);
}
// main.cc
int main() {
Foo foo;
foo.VisitStrings(StringVisitor());
return 0;
}
Having toyed with this I suspect it isn't remotely possible, but I thought I'd ask the experts. I have the following C++ code:
class IInterface
{
virtual void SomeMethod() = 0;
};
class Object
{
IInterface* GetInterface() { ... }
};
class Container
{
private:
struct Item
{
Object* pObject;
[... other members ...]
};
std::list<Item> m_items;
};
I want to add these methods to Container:
MagicIterator<IInterface*> Begin();
MagicIterator<IInterface*> End();
In order that callers can write:
Container c = [...]
for (MagicIterator<IInterface*> i = c.Begin(); i != c.End(); i++)
{
IInterface* pItf = *i;
[...]
}
So essentially I want to provide a class which appears to be iterating over some collection (which the caller of Begin() and End() is not allowed to see) of IInterface pointers, but which is actually iterating over a collection of pointers to other objects (private to the Container class) which can be converted into IInterface pointers.
A few key points:
MagicIterator is to be defined outside Container.
Container::Item must remain private.
MagicIterator has to iterate over IInterface pointers, despite the fact that Container holds a std::list<Container::Item>. Container::Item contains an Object*, and Object can be used to fetch IInterface*.
MagicIterator has to be reusable with several classes which resemble Container, but might internally have different list implementations holding different objects (std::vector<SomeOtherItem>, mylist<YetAnotherItem>) and with IInterface* obtained in a different manner each time.
MagicIterator should not contain container-specific code, though it may delegate to classes which do, provided such delegation is not hard coded to to particular containers inside MagicIterator (so is somehow resolved automatically by the compiler, for example).
The solution must compile under Visual C++ without use of other libraries (such as boost) which would require a license agreement from their authors.
Also, iteration may not allocate any heap memory (so no new() or malloc() at any stage), and no memcpy().
Thanks for your time, even if you're just reading; this one's really been bugging me!
Update: Whilst I've had some very interesting answers, none have met all the above requirements yet. Notably the tricky areas are i) decoupling MagicIterator from Container somehow (default template arguments don't cut it), and ii) avoiding heap allocation; but I'm really after a solution which covers all of the above bullets.
I think you have two separate issues here:
First, create an iterator that will return the IInterface* from your list<Container::Item>. This is easily done with boost::iterator_adaptor:
class cont_iter
: public boost::iterator_adaptor<
cont_iter // Derived
, std::list<Container::Item>::iterator // Base
, IInterface* // Value
, boost::forward_traversal_tag // CategoryOrTraversal
, IInterface* // Reference :)
>
{
public:
cont_iter()
: cont_iter::iterator_adaptor_() {}
explicit cont_iter(const cont_iter::iterator_adaptor_::base_type& p)
: cont_iter::iterator_adaptor_(p) {}
private:
friend class boost::iterator_core_access;
IInterface* dereference() { return this->base()->pObject->GetInterface(); }
};
You would create this type as inner in Container and return in from its begin() and end() methods.
Second, you want the runtime-polymorphic MagicIterator. This is exactly what any_iterator does. the MagicIterator<IInterface*> is just any_iterator<IInterface*, boost::forward_traversal_tag, IInterface*>, and cont_iter can be just assigned to it.
Create an abstract IteratorImplementation class:
template<typename T>
class IteratorImplementation
{
public:
virtual ~IteratorImplementation() = 0;
virtual T &operator*() = 0;
virtual const T &operator*() const = 0;
virtual Iterator<T> &operator++() = 0;
virtual Iterator<T> &operator--() = 0;
};
And an Iterator class to wrap around it:
template<typename T>
class Iterator
{
public:
Iterator(IteratorImplementation<T> * = 0);
~Iterator();
T &operator*();
const T &operator*() const;
Iterator<T> &operator++();
Iterator<T> &operator--();
private:
IteratorImplementation<T> *i;
}
Iterator::Iterator(IteratorImplementation<T> *impl) :
i(impl)
{
}
Iterator::~Iterator()
{
delete i;
}
T &Iterator::operator*()
{
if(!impl)
{
// Throw exception if you please.
return;
}
return (*impl)();
}
// etc.
(You can make IteratorImplementation a class "inside" of Iterator to keep things tidy.)
In your Container class, return an instance of Iterator with a custom subclass of IteratorImplementation in the ctor:
class ObjectContainer
{
public:
void insert(Object *o);
// ...
Iterator<Object *> begin();
Iterator<Object *> end();
private:
class CustomIteratorImplementation :
public IteratorImplementation<Object *>
{
public:
// Re-implement stuff here.
}
};
Iterator<Object *> ObjectContainer::begin()
{
CustomIteratorImplementation *impl = new CustomIteratorImplementation(); // Wish we had C++0x's "var" here. ;P
return Iterator<Object *>(impl);
}
Doesn't sound too complicated. You can define the iterator outside. You can also use typedefs. Something like this would fit i think. Note that it would be way cleaner if that MagicIterator would be not a free template, but a member of Item, typedefed in Container maybe. As it's now, there is a cyclic reference in it, which make it necassary to write some ugly workaround code.
namespace detail {
template<typename T, typename U>
struct constify;
template<typename T, typename U>
struct constify<T*, U*> {
typedef T * type;
};
template<typename T, typename U>
struct constify<T*, U const*> {
typedef T const * type;
};
}
template<typename DstType,
typename Container,
typename InputIterator>
struct MagicIterator;
class Container
{
private:
struct Item
{
Object* pObject;
};
std::list<Item> m_items;
public:
// required by every Container for the iterator
typedef std::list<Item> iterator;
typedef std::list<Item> const_iterator;
// convenience declarations
typedef MagicIterator< IInterface*, Container, iterator >
item_iterator;
typedef MagicIterator< IInterface*, Container, const_iterator >
const_item_iterator;
item_iterator Begin();
item_iterator End();
};
template<typename DstType,
typename Container = Container,
typename InputIterator = typename Container::iterator>
struct MagicIterator :
// pick either const T or T, depending on whether it's a const_iterator.
std::iterator<std::input_iterator_tag,
typename detail::constify<
DstType,
typename InputIterator::value_type*>::type> {
typedef std::iterator<std::input_iterator_tag,
typename detail::constify<
DstType,
typename InputIterator::value_type*>::type> base;
MagicIterator():wrapped() { }
explicit MagicIterator(InputIterator const& it):wrapped(it) { }
MagicIterator(MagicIterator const& that):wrapped(that.wrapped) { }
typename base::value_type operator*() {
return (*wrapped).pObject->GetInterface();
}
MagicIterator& operator++() {
++wrapped;
return *this;
}
MagicIterator operator++(int) {
MagicIterator it(*this);
wrapped++;
return it;
}
bool operator==(MagicIterator const& it) const {
return it.wrapped == wrapped;
}
bool operator!=(MagicIterator const& it) const {
return !(*this == it);
}
InputIterator wrapped;
};
// now that the iterator adepter is defined, we can define Begin and End
inline Container::item_iterator Container::Begin() {
return item_iterator(m_items.begin());
}
inline Container::item_iterator Container::End() {
return item_iterator(m_items.end());
}
Now, start using it:
for(MagicIterator<IInterface*> it = c.Begin(); it != c.End(); ++it) {
// ...
}
You can also use a iterator mixin provided by boost, which works like the input version of boost::function_output_iterator. It calls your iterator's operator() which then returns the appropriate value, doing what we do above in our operator* in principle. You find it in random/detail/iterator_mixin.hpp. That would probably result in fewer code. But it also requires to wrack up our neck to ensure the friend-stuff because Item is private and the iterator isn't defined inside Item. Anyway, good luck :)
It really depends on the Container, because the return values of c.Begin() and c.End() are implementation-defined.
If a list of possible Containers is known to MagicIterator, a wrapper class could be used.
template<typename T>
class MagicIterator
{
public:
MagicIterator(std::vector<T>::const_iterator i)
{
vector_const_iterator = i;
}
// Reimplement similarly for more types.
MagicIterator(std::vector<T>::iterator i);
MagicIterator(std::list<T>::const_iterator i);
MagicIterator(std::list<T>::iterator i);
// Reimplement operators here...
private:
std::vector<T>::const_iterator vector_const_iterator;
std::vector<T>::iterator vector_iterator;
std::list<T>::const_iterator list_const_iterator;
std::list<T>::iterator list_iterator;
};
The easy way would be to use a template which accepts Container's type:
// C++0x
template<typename T>
class Iterator :
public T::iterator
{
using T::iterator::iterator;
};
for(Iterator<Container> i = c.begin(); i != c.end(); ++i)
{
// ...
}
More information here.
I see no reason why you can't implement this exactly as you've laid it out... am I missing something?
To clarify, you'll need to put some kind of accessor methods on your Container class. They can be private and you can declare MagicIterator as a friend, if you feel that's the best way to encapsulate it, but I'd expose them directly. These accessor methods would use a normal STL iterator inside Container and perform the conversion to IInterface. Thus the iterating would actually be done with the Container's accessor methods and MagicIterator would just be a kind of proxy object to make it easier. To make it reentrant, you could have the MagicIterator pass in some kind of ID to look up the STL iterator inside Container, or you could actually have it pass in the STL iterator as a void *.
I've now found a solution which is fitter for my original purpose. I still don't like it though :)
The solution involves MagicIterator being templated on IInterface* and being constructed with both a void* to an iterator, the byte size of said iterator, and a table of pointers to functions which perform standard iteration functions on said void* such as increment, decrement, dereference, etc. MagicIterator assumes that it is safe to memcpy the given iterator into an internal buffer, and implements its own members by passing its own buffer as a void* to the supplied functions as if it were the original iterator.
Container then has to implement static iteration functions which cast back a supplied void* to a std::list::iterator. Container::begin() and Container::end() simply construct a std::list::iterator, pass a pointer to it into a MagicIterator along with a table of its iteration functions, and return the MagicIterator.
It's somewhat disgusting, and breaks my original rule regarding "no memcpy()", and makes assumptions about the internals of the iterators in question. But it avoids heap allocation, keeps Collection's internals (including Item) private, renders MagicIterator entirely independent of the collection in question and of IInterface*, and in theory allows MagicIterators to work with any collection (provided its iterators can be safely memcopy()'d).
A visitor may be a simpler (and therefore easier to maintain) solution.