I'm looking for a way to create a forward iterator which allows to iterate over a collection of hash maps.
An exemplary class which holds several maps looks like follows. (I'm using boost for unordered_map and shared_ptr, but C++11 would provide those classes as well).
In my particular application I'm using this construct to represent sparse hierarchical 2D grid locations; i.e. KeyT is a 2D location, ValueT is an integral counter and the different levels represent different resolutions of the grid.
template <typename KeyT, typename ValueT>
class MapCollection
{
public:
// type-definitions for the map and a shared pointer to the map
typedef boost::unordered_map<KeyT, ValueT> Map;
typedef boost::shared_ptr<Map> MapPtr;
// Constructor for class
MapCollection (int num_levels)
{
levels_.reserve (num_levels);
for (int i = 0; i < num_levels; ++i)
levels_.push_back (MapPtr (new Map()));
}
// adds a key-value pair to the map on the given level
void addValue (const KeyT &key, const ValueT &value)
{
int level = getLevelForKey (key);
(*levels_[level])[key] = value;
}
// TODO define const_iterator for this class
// TODO define member function begin(), returning levels_.front()->begin()
// TODO define member function end(), returning levels_.back()->end()
private:
// return the hierarchy level for the given key
int getLevelForKey (const KeyT &key) { return /* ... */ };
// collection of maps
std::vector<MapPtr> levels_;
};
Within an application I would now like to be able to iterate over all entries of all maps, similarly to what is possible if one just iterates over a single map, i.e.
int main (int argc, char *argv[])
{
int num_levels = 5;
MapCollection maps (num_levels);
// fill maps
maps.addValue ( /* ... */ )
// iterator over all entries
MapCollection::const_iterator iter = maps.begin();
for (; iter != maps.end(); ++iter)
{
std::cout << "Key: " << iter->first << " | Value: " << iter->second << std::endl;
}
return EXIT_SUCCESS;
}
Obviously it would be possible to iterator over the different levels and for each level over it's map, but I would like to hide the creation of different levels for the user.
What is the correct way to define an (const_)iterator for the class MapCollection?
Thanks for your help!
You could use boost iterator facade, that will help you with the task of implementing custom iterators. The idea would be:
1-maintain a reference to the vector containing the maps (levels_).
2-a iterator indicating what element of the previous vector the custom iterator is iterating (of type std::vector<MapPtr>::iterator or std::vector<MapPtr>::const_iterator) or a index with the same info (to retrieve the end of level_[index]).
3-a iterator with current element of the iteration of the previous iterator (the actual element of the iteration).
Some sample code:
#include <boost/iterator/iterator_facade.hpp>
namespace impl
{
template <class Value>
class iterator
: public boost::iterator_facade<
config_iterator<Value>
, Value
, boost::forward_traversal_tag
>
{
public:
config_iterator() {...}
explicit config_iterator(parameters) { /*your specific contructor*/ }
private:
template <class OtherValue>
config_iterator(config_iterator<OtherValue> const& other);
friend class boost::iterator_core_access;
template <class> friend class config_iterator;
template <class OtherValue>
bool equal(config_iterator<OtherValue> const& other) const { } // Verify is two iterators are equals (used to verify if it == end)
void increment() {} // Logic for incrementing the iterator
Value& dereference() const {} // Returning the actual value
// members
};
}
typedef impl::iterator<type> iterator;
This is a template file for very simple iterator (forward), read the Iterator Help for more info, the same can be implementing overloading the right operators (++ post a pre increment, *, ->, etc...), by boost provide a ways of defining the minimum necessary to implement the rest.
Related
I have a big vector of items that belong to a certain class.
struct item {
int class_id;
//some other data...
};
The same class_id can appear multiple times in the vector, and the vector is constructed once and then sorted by class_id. So all elements of the same class are next to each other in the vector.
I later have to process the items per class, ie. I update all items of the same class but I do not modify any item of a different class. Since I have to do this for all items and the code is trivially parallelizable I wanted to use Microsoft PPL with Concurrency::parallel_for_each(). Therefore I needed an iterator and came up with a forward iterator that returns the range of all items with a certain class_id as proxy object. The proxy is simply a std::pair and the proxy is the iterator's value type.
using item_iterator = std::vector<item>::iterator;
using class_range = std::pair<item_iterator, item_iterator>;
//iterator definition
class per_class_iterator : public std::iterator<std::forward_iterator_tag, class_range> { /* ... */ };
By now I was able to loop over all my classes and update the items like this.
std::vector<item> items;
//per_class_* returns a per_class_iterator
std::for_each(items.per_class_begin(), items.per_class_end(),
[](class_range r)
{
//do something for all items in r
std::for_each(r.first, r.second, /* some work */);
});
When replacing std::for_each with Concurrency::parallel_for_each the code crashed. After debugging I found the problem to be the following code in _Parallel_for_each_helper in ppl.h at line 2772 ff.
// Add a batch of work items to this functor's array
for (unsigned int _Index=0; (_Index < _Size) && (_First != _Last); _Index++)
{
_M_element[_M_len++] = &(*_First++);
}
It uses postincrement (so a temporary iterator is returned), dereferences that temporary iterator and takes the address of the dereferenced item. This only works if the item returned by dereferencing a temporary object survives, ie. basically if it points directly into the container. So fixing this is easy, albeit the per class std::for_each work loop has to be replaced with a for-loop.
//it := iterator somewhere into the vector of items (item_iterator)
for(const auto cur_class = it->class_id; cur_class == it->class_id; ++it)
{
/* some work */
}
My question is if returning proxy objects the way I did is violating the standard or if the assumption that every iterator dereferences into permanent data has been made by Microsoft for their library, but is not documented. At least I could not find any documentation on the iterator requirements for parallel_for_each() except that either a random access or a forward iterator are expected. I have seen the question about forward iterators and vector but since my iterator's reference type is const value_type& I still think my iterator is ok by the standard. So is a forward iterator returning a proxy object still a valid forward iterator? Or put another way, is it ok for an iterator to have a value type different from a type that is actually stored somewhere in a container?
Compilable example:
#include <vector>
#include <utility>
#include <cassert>
#include <iterator>
#include <memory>
#include <algorithm>
#include <iostream>
#include <ppl.h>
using identifier = int;
struct item
{
identifier class_id;
// other data members
// ...
bool operator<(const item &rhs) const
{
return class_id < rhs.class_id;
}
bool operator==(const item &rhs) const
{
return class_id == rhs.class_id;
}
//inverse operators omitted
};
using container = std::vector<item>;
using item_iterator = typename container::iterator;
using class_range = std::pair<item_iterator, item_iterator>;
class per_class_iterator : public std::iterator<std::forward_iterator_tag, class_range>
{
public:
per_class_iterator() = default;
per_class_iterator(const per_class_iterator&) = default;
per_class_iterator& operator=(const per_class_iterator&) = default;
explicit per_class_iterator(container &data) :
data_(std::addressof(data)),
class_(equal_range(data_->front())), //this would crash for an empty container. assume it's not.
next_(class_.second)
{
assert(!data_->empty()); //a little late here
assert(std::is_sorted(std::cbegin(*data_), std::cend(*data_)));
}
reference operator*()
{
//if data_ is unset the iterator is an end iterator. dereferencing end iterators is bad.
assert(data_ != nullptr);
return class_;
}
per_class_iterator& operator++()
{
assert(data_ != nullptr);
//if we are at the end of our data
if(next_ == data_->end())
{
//reset the data pointer, ie. make iterator an end iterator
data_ = nullptr;
}
else
{
//set to the class of the next element
class_ = equal_range(*next_);
//and update the next_ iterator
next_ = class_.second;
}
return *this;
}
per_class_iterator operator++(int)
{
per_class_iterator tmp{*this};
++(*this);
return tmp;
}
bool operator!=(const per_class_iterator &rhs) const noexcept
{
return (data_ != rhs.data_) ||
(data_ != nullptr && rhs.data_ != nullptr && next_ != rhs.next_);
}
bool operator==(const per_class_iterator &rhs) const noexcept
{
return !(*this != rhs);
}
private:
class_range equal_range(const item &i) const
{
return std::equal_range(data_->begin(), data_->end(), i);
}
container* data_ = nullptr;
class_range class_;
item_iterator next_;
};
per_class_iterator per_class_begin(container &c)
{
return per_class_iterator{c};
}
per_class_iterator per_class_end()
{
return per_class_iterator{};
}
int main()
{
std::vector<item> items;
items.push_back({1});
items.push_back({1});
items.push_back({3});
items.push_back({3});
items.push_back({3});
items.push_back({5});
//items are already sorted
//#define USE_PPL
#ifdef USE_PPL
Concurrency::parallel_for_each(per_class_begin(items), per_class_end(),
#else
std::for_each(per_class_begin(items), per_class_end(),
#endif
[](class_range r)
{
//this loop *cannot* be parallelized trivially
std::for_each(r.first, r.second,
[](item &i)
{
//update item (by evaluating all other items of the same class) ...
//building big temporary data structure for all items of same class ...
//i.processed = true;
std::cout << "item: " << i.class_id << '\n';
});
});
return 0;
}
When you're writing a proxy iterator, the reference type should be a class type, precisely because it can outlive the iterator it is derived from. So, for a proxy iterator, when instantiating the std::iterator base should specify the Reference template parameter as a class type, typically the same as the value type:
class per_class_iterator : public std::iterator<
std::forward_iterator_tag, class_range, std::ptrdiff_t, class_range*, class_range>
~~~~~~~~~~~
Unfortunately, PPL is not keen on proxy iterators and will break compilation:
ppl.h(2775): error C2338: lvalue required for forward iterator operator *
ppl.h(2772): note: while compiling class template member function 'Concurrency::_Parallel_for_each_helper<_Forward_iterator,_Function,1024>::_Parallel_for_each_helper(_Forward_iterator &,const _Forward_iterator &,const _Function &)'
with
[
_Forward_iterator=per_class_iterator,
_Function=main::<lambda_051d98a8248e9970abb917607d5bafc6>
]
This is actually a static_assert:
static_assert(std::is_lvalue_reference<decltype(*_First)>::value, "lvalue required for forward iterator operator *");
This is because the enclosing class _Parallel_for_each_helper stores an array of pointers and expects to be able to indirect them later:
typename std::iterator_traits<_Forward_iterator>::pointer _M_element[_Size];
Since PPL doesn't check that pointer is actually a pointer, we can exploit this by supplying a proxy pointer with an operator* and overloading class_range::operator&:
struct class_range_ptr;
struct class_range : std::pair<item_iterator, item_iterator> {
using std::pair<item_iterator, item_iterator>::pair;
class_range_ptr operator&();
};
struct class_range_ptr {
class_range range;
class_range& operator*() { return range; }
class_range const& operator*() const { return range; }
};
inline class_range_ptr class_range::operator&() { return{*this}; }
class per_class_iterator : public std::iterator<
std::forward_iterator_tag, class_range, std::ptrdiff_t, class_range_ptr, class_range&>
{
// ...
This works great:
item: item: 5
1
item: 3item: 1
item: 3
item: 3
Press any key to continue . . .
For your direct question, no, iterator does not have to be something which is related to any kind of container. About only requirements for an iterator are for it to be:
be copy-constructible, copy-assignable and destructible
support equality/inequality
be dereferencable
Iterator does not necessarily has to be tied to a particular container (see generators), and so it cannot be said that "it has to has same type as container" - because there is no container in generic case.
It seems, hovever, having a custom iterator class may be actually an overkill in your case. Here's why:
In C++, array/vector end iterator is and iterator pointing just behind the end of the last item.
Given a vector of objects of "classes" (in your definition) A,B,C, etc., filled like following:
AAAAAAABBBBBBBBBBBBCCCCCCCD.......
You can just take regular vector iterators that will act as your range starts and ends:
AAAAAAABBBBBBBBBBBBCCCCCCCD......Z
^ ^ ^ ^ ^
i1 i2 i3 i4 iN
For the 4 iterators you see here, following is true:
i1 is begin iterator for class A
i2 is end iterator for class A and begin iterator for class B
i3 is end iterator for class B and begin iterator for class C etc.
Hence, for each class you can have a pair of iterators which are start and end of the respective class range.
Hence, your processing is as trivial as:
for(auto it = i1; i!= i2; i++) processA(*it);
for(auto it = i2; i!= i3; i++) processB(*it);
for(auto it = i3; i!= i4; i++) processC(*it);
Each loop being trivially parallelizable.
parallel_for_each (i1; i2; processA);
parallel_for_each (i2; i3; processB);
parallel_for_each (i3; i4; processC);
To use a range-based for, you can introduce a substitute range class:
class vector_range<T> {
public:
vector<T>::const_iterator begin() {return _begin;};
vector<T>::const_iterator end() {return _end;};
// Trivial constructor filling _begin and _end fields
}
That is to say, you don't really need a proxy iterators to parallelize loops - the way C++ iterators are done is already ideally covers your case.
I created a simple bidirectional map class that works by internally storing two std::map instances, with opposite key/value types, and providing a user-friendly interface:
template<class T1, class T2> class Bimap
{
std::map<T1, T2> map1;
std::map<T2, T1> map2;
// ...
};
Is there a more efficient method of implementing a bidirectional map that doesn't require twice the memory?
How is a bimap usually implemented?
EDIT:
Should bimap element be mutable or immutable? (Changing one element in map1 should change the key in map2, but keys are const and that's impossible - what's the solution?)
Ownership of elements is also another problem: when a user inserts a key-value pair in the bimap, the bimap should make a copy of that key-value pair and store it, then the internal second map (with inverted key/value) should not copy but point to the original pair. How can this be achieved?
EDIT 2:
I've posted a possible implementation I made on Code Review.
There is a certain problem with double-storing your data in all simple implementations of a bimap. If you can break it down to a bimap of pointers from outside, then you can readily ignore this and simply keep both maps of the form std::map<A*,B*> like Arkaitz Jimenez already suggested (though contrary to his answer you have to care about the storage from outside to avoid a A->A* lookup). But if you have the pointers anyway, why not simply store a std::pair<A,B> at the point where you would otherwise store A and B separately?
It would be nice to have std::map<A,B*> instead of std::map<A*,B*> as this would allow for example the lookup of an element associated to an string by a newly created string with the same content instead of the pointer to the original string that created the pair. But it is customary to store a full copy of the key with every entry and only rely on the hash to find the right bucket. This way the returned item will be the correct one even in the case of a hash-collision...
If you want to have it quick and dirty though, there is this
hackish solution:
Create two maps std::map<size_t, A> mapA and std::map<size_t, B> mapB. Upon insertion hash both elements that are to be inserted to get the keys to the respective maps.
void insert(const A &a, const B &b) {
size_t hashA = std::hash<A>(a);
size_t hashB = std::hash<B>(b);
mapA.insert({hashB, a});
mapB.insert({hashA, b});
}
Lookup is implemented analogously.
Using a multimap instead of a map and verifying every element you get with a lookup in the respectively other map (get candidate b from mapA, hash b and look in mapB if it matches the wanted key, iterate to the next candidate b otherwise) this is a valid implementation - but still hackish in my opinion...
You can get a much nicer solution by using the copies of the elements that are used to compare the entries (see above) as only storage. It is a bit harder to get your head around that though. To elaborate:
a nicer solution:
Create two sets of pairs as std::set<pair<A, B*>> and std::set<pair<B, A*>> and overload the operator< and operator== to only take the first element of the pairs into account (or provide an corresponding comparion class). It is necessary to create sets of pairs instead of maps (which internally look similarly) because we need a guarantee that A and B will be at constant positions in memory. Upon insertion of an pair<A, B> we split it into two elements that fit into the above sets.
std::set<pair<B, A*>> mapA;
std::set<pair<A, B*>> mapB;
void insert(const A &a, const B &b) {
auto aitr = mapA.insert({b, nullptr}).first; // creates first pair
B *bp = &(aitr->first); // get pointer of our stored copy of b
auto bitr = mapB.insert({a, bp}).first;
// insert second pair {a, pointer_to_b}
A *ap = &(bitr->first); // update pointer in mapA to point to a
aitr->second = ap;
}
Lookup can now simply be done by a simple std::set lookup and a pointer dereference.
This nicer solution is similar to the solution that boost uses - even though they use some annonymized pointers as second elements of the pairs and thus have to use reinterpret_casts.
Note that the .second part of the pairs need to be mutable (so I'm not sure std::pair can be used), or you have to add another layer of abstraction (std::set<pair<B, A**>> mapA) even for this simple insertion. In both solutions you need temporary elements to return non-const references to elements.
It would be more efficient to store all elements in a vector and have 2 maps of <T1*,T2*> and <T2*,T1*> that way you would not have everything copied twice.
The way I see it you are trying to store 2 things, elements themselves and the relationship between them, if you are aiming to scalar types you could leave it as is 2 maps, but if you aim to treat complex types it makes more sense to separate the storage from the relationships, and handle relationships outside the storage.
Boost Bimap makes use of Boost Mutant Idiom.
From the linked wikipedia page:
Boost mutant idiom makes use of reinterpret_cast and depends heavily on assumption that the memory layouts of two different structures with identical data members (types and order) are interchangeable. Although the C++ standard does not guarantee this property, virtually all the compilers satisfy it.
template <class Pair>
struct Reverse
{
typedef typename Pair::first_type second_type;
typedef typename Pair::second_type first_type;
second_type second;
first_type first;
};
template <class Pair>
Reverse<Pair> & mutate(Pair & p)
{
return reinterpret_cast<Reverse<Pair> &>(p);
}
int main(void)
{
std::pair<double, int> p(1.34, 5);
std::cout << "p.first = " << p.first << ", p.second = " << p.second << std::endl;
std::cout << "mutate(p).first = " << mutate(p).first << ", mutate(p).second = " << mutate(p).second << std::endl;
}
The implementation in boost sources is of course fairly hairier.
If you create a set of pairs to your types std::set<std::pair<X,Y>> you pretty much have your functionallity implemented and rules about mutabillity and constness preset (OK maybe the settings aren't what you want but tweaks can be made). So here is the code :
#ifndef MYBIMAP_HPP
#define MYBIMAP_HPP
#include <set>
#include <utility>
#include <algorithm>
using std::make_pair;
template<typename X, typename Y, typename Xless = std::less<X>,
typename Yless = std::less<Y>>
class bimap
{
typedef std::pair<X, Y> key_type;
typedef std::pair<X, Y> value_type;
typedef typename std::set<key_type>::iterator iterator;
typedef typename std::set<key_type>::const_iterator const_iterator;
struct Xcomp
{
bool operator()(X const &x1, X const &x2)
{
return !Xless()(x1, x2) && !Xless()(x2, x1);
}
};
struct Ycomp
{
bool operator()(Y const &y1, Y const &y2)
{
return !Yless()(y1, y2) && !Yless()(y2, y1);
}
};
struct Fless
{ // prevents lexicographical comparison for std::pair, so that
// every .first value is unique as if it was in its own map
bool operator()(key_type const &lhs, key_type const &rhs)
{
return Xless()(lhs.first, rhs.first);
}
};
/// key and value type are interchangeable
std::set<std::pair<X, Y>, Fless> _data;
public:
std::pair<iterator, bool> insert(X const &x, Y const &y)
{
auto it = find_right(y);
if (it == end()) { // every .second value is unique
return _data.insert(make_pair(x, y));
}
return make_pair(it, false);
}
iterator find_left(X const &val)
{
return _data.find(make_pair(val,Y()));
}
iterator find_right(Y const &val)
{
return std::find_if(_data.begin(), _data.end(),
[&val](key_type const &kt)
{
return Ycomp()(kt.second, val);
});
}
iterator end() { return _data.end(); }
iterator begin() { return _data.begin(); }
};
#endif
Example usage
template<typename X, typename Y, typename In>
void PrintBimapInsertion(X const &x, Y const &y, In const &in)
{
if (in.second) {
std::cout << "Inserted element ("
<< in.first->first << ", " << in.first->second << ")\n";
}
else {
std::cout << "Could not insert (" << x << ", " << y
<< ") because (" << in.first->first << ", "
<< in.first->second << ") already exists\n";
}
}
int _tmain(int argc, _TCHAR* argv[])
{
bimap<std::string, int> mb;
PrintBimapInsertion("A", 1, mb.insert("A", 1) );
PrintBimapInsertion("A", 2, mb.insert("A", 2) );
PrintBimapInsertion("b", 2, mb.insert("b", 2));
PrintBimapInsertion("z", 2, mb.insert("z", 2));
auto it1 = mb.find_left("A");
if (it1 != mb.end()) {
std::cout << std::endl << it1->first << ", "
<< it1->second << std::endl;
}
auto it2 = mb.find_right(2);
if (it2 != mb.end()) {
std::cout << std::endl << it2->first << ", "
<< it2->second << std::endl;
}
return 0;
}
NOTE: All this is a rough code sketching of what a full implementation would be and even after polishing and extending the code I'm not implying that this would be an alternative to boost::bimap but merely a homemade way of having an associative container searchable by both the value and the key.
Live example
One possible implementation that uses an intermediate data structure and an indirection is:
int sz; // total elements in the bimap
std::map<A, int> mapA;
std::map<B, int> mapB;
typedef typename std::map<A, int>::iterator iterA;
typedef typename std::map<B, int>::iterator iterB;
std::vector<pair<iterA, iterB>> register;
// All the operations on bimap are indirected through it.
Insertion
Suppose you have to insert (X, Y) where X, Y are instances of A and B respectively, then:
Insert (X, sz) in mapA --- O(lg sz)
Insert (Y, sz) in mapB --- O(lg sz)
Then push_back (IterX, IterY) in register --- O(1). Here IterX and IterY are iterators to the corresponding element in mapA and mapB and are obtained from (1) and (2) respectively.
Lookup
Lookup for the image of an element, X, of type A:
Get the int mapped to X in mapA. --- O(lg n)
Use the int to index into register and get corresponding IterY. --- O(1)
Once you have IterY, you can get Y through IterY->first. --- O(1)
So both the operations are implemented in O(lg n).
Space: All the copies of the objects of A and B are required to be stored only once. There is, however, a lot of bookkeeping stuff. But when you have large objects, that would also be not much significant.
Note: This implementation relies on the fact that the iterators of a map are never invalidated. Hence, the contents of register are always valid.
A more elaborate version of this implementation can be found here
How about this?
Here, we avoid double storage of one type (T1). The other type (T2) is still double stored.
// Assume T1 is relatively heavier (e.g. string) than T2 (e.g. int family).
// If not, client should instantiate this the other way.
template <typename T1, typename T2>
class UnorderedBimap {
typedef std::unordered_map<T1, T2> Map1;
Map1 map1_;
std::unordered_map<T2, Map1::iterator> map2_;
};
I am using C++ to implement a square list which is a doubly-linked list of doubly-linked lists. The list is sorted, and the idea is that the structure maintains the shape of a square as elements are inserted and erased. If the list has four elements in total that square would be in a 2x2 shape.
It looks something like this:
I've done some research on linked lists and understand that the general idea is to create nodes that hold each data element, as well as pointers to and from the surrounding elements, but one thing that's throwing me off is how I would (or could) implement an iterator to traverse the square list.
This is my first time attempting to build a data structure, so the process in general is pretty new to me. Any tips appreciated!
There are a few design decisions you need to make, like whether it matters if the overall iteration exhausts each "inner" list in turn, or should return the first elements of all inner lists, then the second etc..
As a taste of how to implement this:
#include <iostream>
#include <list>
template <typename T>
struct Iterator
{
typedef typename std::list<std::list<T> >::iterator outer_iterator;
typedef typename std::list<T>::iterator inner_iterator;
outer_iterator outer_;
bool inner_initialised_;
inner_iterator inner_;
Iterator(outer_iterator begin)
: outer_(begin), inner_initialised_(false)
{ }
T& operator*()
{
if (!inner_initialised_)
{
inner_ = outer_->begin();
inner_initialised_ = true;
}
return *inner_;
}
T& operator->() { return operator*(); }
Iterator& operator++()
{
if (++inner_ == outer_->end())
{
++outer_;
inner_initialised_ = false;
}
return *this;
}
bool operator!=(outer_iterator i) const { return outer_ != i; }
};
int main()
{
std::list<std::list<int>> lli;
std::list<int> li;
li.push_back(42);
li.push_back(13);
lli.push_back(li);
li.push_back(999);
lli.push_back(li);
for (Iterator<int> i = lli.begin(); i != lli.end(); ++i)
std::cout << *i << ' ';
std::cout << '\n';
}
Output:
42 13 42 13 999
Notice the bool inner_initialised_ variable - it ensures no attempt is made to call ->begin() on an outer iterator value equal to end().
You'll probably want to flesh that out a little with operator==, ++(int), --, a const version for const_iterators etc. for more general usage. I'd normally make the custom iterator class a member of the custom container class, providing begin() and end() that yield custom iterator objects, but I'm not sure if you're planning to have an actual "square list" class or just use list<list<T>> everywhere.
Question Synopsis
Given a std::vector<T>, how can I create a view that exposes the interface of a std::vector<std::pair<T, T>>, where each pair consists of two consecutive elements in the underlying vector?
Details
The goal is to create multiple container abstractions over the same storage, which is a std::vector<T>. The type T is some sort of discriminated union, à la Boost Variant. The storage requirement is given, otherwise I would simply use a std::vector<std::pair<T, T>>. The views over the storage I would like to support are sets (unique elements) and tables (associative array, unique keys). While the former is straight-forward by ensuring the set uniqueness property, the latter requires handling keys and values.
To support associative array semantics over a std::vector<T>, I am currently thinking that the best way would be to create a view of the form std::vector<std::pair<T, T>>, and that this view would allow me use STL algorithms to maintain the required properties. Does this sound like a good strategy? Are there any other ideas?
Related
If I had an iterator i that goes over every even element and iterator j that goes through every odd element, Boost's zip iterator comes to mind, which would enable iteration in (i,j) pairs. But my use case is slightly different in that I do not have two separate containers.
It seems that Boost's iterator_facade is indeed what I want. Here is a toy example (with rough edges):
#include <algorithm>
#include <iostream>
#include <vector>
#include <boost/iterator/iterator_facade.hpp>
template <typename Value>
class pair_iterator
: public boost::iterator_facade<
pair_iterator<Value>
, Value
, boost::random_access_traversal_tag
, std::pair<Value&, Value&>
, typename std::vector<Value>::difference_type
>
{
public:
typedef std::vector<Value> vector_type;
typedef typename vector_type::difference_type difference_type;
typedef typename vector_type::iterator iterator;
pair_iterator()
: i_(0)
{
}
explicit pair_iterator(iterator i)
: i_(i)
{
}
private:
friend class boost::iterator_core_access;
bool equal(pair_iterator<Value> const& other) const
{
return i_ == other.i_;
}
void increment()
{
++i_;
++i_;
}
std::pair<Value&, Value&> dereference() const
{
return { std::ref(*i_), std::ref(*(i_ + 1)) };
}
void advance(difference_type n)
{
i_ += n << 1;
}
difference_type distance_to(pair_iterator<Value> const& other) const
{
return other.i_ - i_;
}
iterator i_;
};
int main()
{
typedef pair_iterator<int> int_map_iterator;
std::vector<int> v{2, 20, 3, 30, 5, 50, 7, 70};
int_map_iterator first(v.begin());
int_map_iterator last(v.end());
std::for_each(first + 1, last,
[](std::pair<int&, int&> p)
{
std::cout
<< p.first << " -> "
<< p.second << std::endl;
});
return 0;
}
The output is:
3 -> 30
5 -> 50
7 -> 70
Issues
Conversion from iterator to const_iterator has not yet been addressed by this example.
The iterator only works when the underlying vector has even size and needs a more conservative implementation of dereference().
The first thing to note is that you won't be able to expose a std::pair<T const, T>& as a means to modify the objects. What may be sufficantly close, however, is a std::pair<T const, T&> as you'll only be able to change the second part.
With this out of the way it seems you need
An iterator type which skips every other value and is used to iterate over the keys (elements with even indices) and the values (elements with odd indices).
Something like a "zip iterator" which takes two iterators and exposes a std::pair<T const, T&> obtained from them.
I have a need for a "container" that acts like the following. It has 2 subcontainers, called A and B, and I need to be able to iterate over just A, just B, and A and B combined. I don't want to use extra space for redundant data, so I thought of making my own iterator to iterate over A and B combined. What is the easiest way to make your own iterator? Or, what is another way to do this?
EDIT Ultimately, I don't think it was good design. I have redesigned the entire class heirarchy. +1 for refactoring. However, I did solve this problem sufficiently. Here's an abbreviated version of what I did, for reference; it uses boost::filter_iterator. Let T be the type in the container.
enum Flag
{
A_flag,
B_flag
};
class T_proxy
{
public:
T_proxy(const T& t, Flag f) : t_(t), flag_(f) {}
operator T() const {return t_;}
Flag flag() const {return flag_;}
class Compare
{
public:
Compare(Flag f) : matchFlag_(f) {}
operator() (const T_proxy& tp) {return tp.flag() == matchFlag_;}
private:
Flag matchFlag_;
};
private:
T t_;
Flag flag_;
};
class AB_list
{
public:
typedef T_proxy::Compare Compare;
typedef vector<T_proxy>::iterator iterator;
typedef boost::filter_iterator<Compare, iterator> sub_iterator;
void insert(const T& val, Flag f) {data_.insert(T_proxy(val, f));}
// other methods...
// whole sequence
iterator begin() {return data_.begin();}
iterator end() {return data_.end();}
// just A
sub_iterator begin_A() {return sub_iterator(Compare(A_flag), begin(), end());
sub_iterator end_A() {return sub_iterator(Compare(A_flag), end(), end());
// just B is basically the same
private:
vector<T_proxy> data_;
};
// usage
AB_list mylist;
mylist.insert(T(), A_flag);
for (AB_list::sub_iterator it = mylist.begin_A(); it != mylist.end_A(); ++it)
{
T temp = *it; // T_proxy is convertible to T
cout << temp;
}
I will repost my answer to a similar question. I think this will do what you want.
Use a library like Boost.MultiIndex to do what you want. It scales well and there is a lot less boiler plate code if you want to add new indexes. It is also usually more space and time efficient
typedef multi_index_container<
Container,
indexed_by<
sequenced<>, //gives you a list like interface
ordered_unique<Container, std::string, &Container::a_value>, //gives you a lookup by name like map
ordered_unique<Container, std::string, &Container::b_value> //gives you a lookup by name like map
>
> container;
If you are iterating over one index, you can switch to another index by using the iterator projection concept in the library.
Have one container which stores the value you are interested in together with a flag indicating whether it is in A or B.
You could also create a single container containing std::pair<> objects.
Billy3