An approach inspired by Barry below would be to write a range adapter.
Doing this without boost or similar library support is a pain, but:
Write a range template. It stores 2 class iterators and has begin() and end() methods (and whatever else you want).
Write a transforming iterator adapter. It takes an iterator, and wraps it up so that its value type is transformed by some function object F.
Write a to_kv transformer that takes a std::pair<K, V> cv& and returns a struct kv_t { K cv& key; V cv& value; }.
Wire 3 into 2 into 1 and call it as_kv. It takes a range of pairs, and returns a range of key-values.
The syntax you end up with is:
std::map<int, std::string> m;
for (auto kv : as_kv(m)) {
std::cout << kv.key << "->" << kv.value << "\n";
}
which is nice.
Here is a minimalist solution that doesn't actually create legal iterators, but does support for(:):
template<class Key, class Value>
struct kv_t {
Key&& key;
Value&& value;
};
// not a true iterator, but good enough for for(:)
template<class Key, class Value, class It>
struct kv_adapter {
It it;
void operator++(){ ++it; }
kv_t<Key const, Value> operator*() {
return {it->first, it->second};
}
friend bool operator!=(kv_adapter const& lhs, kv_adapter const& rhs) {
return lhs.it != rhs.it;
}
};
template<class It, class Container>
struct range_trick_t {
Container container;
range_trick_t(Container&&c):
container(std::forward<Container>(c))
{}
It begin() { return {container.begin()}; }
It end() { return {container.end()}; }
};
template<class Map>
auto as_kv( Map&& m ) {
using std::begin;
using iterator = decltype(begin(m)); // no extra (())s
using key_type = decltype((begin(m)->first)); // extra (())s on purpose
using mapped_type = decltype((begin(m)->second)); // extra (())s on purpose
using R=range_trick_t<
kv_adapter<key_type, mapped_type, iterator>,
Map
>;
return R{std::forward<Map>(m)};
}
std::map<int, std::string> m() { return {{0, "Hello"}, {2, "World"}}; }
which is very minimal, but works. I would not generally encourage this kind of half-assed pseudo iterators for for(:) loops; using real iterators is only a modest additional cost, and doesn't surprise people later on.
live example
(Now with temporary map support. Does not support flat C arrays ... yet)
The range-trick stores a container (possibly a reference) in order to copy temporary containers into the object stored for the duration of the for(:) loop. Non-temporary containers the Container type is a Foo& of some kind, so it doesn't make a redundant copy.
On the other hand, kv_t obviously only stores references. There could be a strange case of iterators returning temporaries that break this kv_t implementation, but I'm uncertain how to avoid it in general without sacrificing performance in more common cases.
If you don't like the kv. part of the above, we can do some solutions, but they aren't as clean.
template<class Map>
struct for_map_t {
Map&& loop;
template<class F>
void operator->*(F&& f)&&{
for (auto&& x:loop) {
f( decltype(x)(x).first, decltype(x)(x).second );
}
}
};
template<class Map>
for_map_t<Map> map_for( Map&& map ) { return {std::forward<Map>(map)}; }
then:
map_for(m)->*[&](auto key, auto& value) {
std::cout << key << (value += " ") << '\n';
};
close enough?
live example
There are some proposals around first-class tuples (and hence pairs) that may give you something like that, but I do not know the status of the proposals.
The syntax you may end up if this gets into C++ would look something like this:
for( auto&& [key, value] : container )
Comments on the ->* abomination above:
So the ->* is being used sort of as an operator bind from Haskell (together with implicit tuple unpacking), and we are feeding it a lambda that takes the data contained within the map and returns void. The (Haskell-esque) return type becomes a map over void (nothing), which I elide into void.
The technique has a problem: you lose break; and continue; which suck.
A less hackey Haskell-inspired variant would expect the lambda to return something like void | std::experimental::expected<break_t|continue_t, T>, and if T is void return nothing, if T is a tuple-type return a map, and if T is a map join the returned map-type. It would also either unpack or not unpack the contained tuple depending on what the lambda wants (SFINAE-style detection).
But that is a bit much for a SO answer; this digression points out that the above style of programming isn't a complete dead-end. It is unconventional in C++ however.
