Hello Ovanes,
----- Mensaje original -----
De: Ovanes Markarian
Hello all,
working with boost multi-index container requires sometimes some effort in regards of correct tagging (or at least some typing work ;). I found the following approach to be useful and may be it can be integrated in the multi-index library.
First of all the dealing with searchable collections (STL collections are no exception) can be really nasty in regards of finding an iterator and comparing it with the end iterator. The following function can really be of help:
[...]
template
inline boost::iterator_range<typename T::const_iterator> find_range(T const& container, K const& key) { return boost::make_iterator_range( container.find(key),container.end()); } //non-const version follows as well ...
Actually iterator_range defines a "bool"- and "!"- (NOT) operators. iterator_range is returned by this function. Therefore constructs like: std::setstd::string some_set;
if(!find_range(some_set, "my_key")) some_set.insert("my_key");
are possible without the need of accesing the underlying iterator types or explicitly comparing the found iterator with the end iterator.
I've got some doubts about your construct:
1. The syntax to check whether a value has been found or not is
certainly clearer, but at the expense of a more convoluted
expression to get the value found:
const std::string& v=
*boost::begin(find_range(some_set,"my_key"));
And the type of the construct returned by find_range is also somewhat
messy to type down (at least until compilers come with decltype and
auto):
boost::iterator_range
The next step dealing with Multi-Index container turned out in multipletypedefs for every tagged type. The main disadvantage in this approach was to constantly retrieve the required container view and related iterator, so I came up the the following class:
[...] This also could benefit of a more specific locator-based interface, IMHO. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo