range-for support shared by every dxd type whose elements aren't already kept in an STL container of their own (dx::key_value_tree, cf::data, cf::dictionary, cf::array): a derived_t populates container_t however it needs to - a single existing conversion, or an explicit per-element loop - in its own constructor, then calls seed() once population is complete; operator++()/operator!=() forward to container_t's own iterator from then on. operator*() stays derived_t's own: what it should return (a plain element, const or not) differs per user, from cf::data's read-only bytes to dx::key_value_tree's mutable, further-navigable child node. More...

#include <dx_iterator.h>

Public Types
using	dx_iterator_tag = void

Public Member Functions
	iterator ()=default
bool	operator!= (const iterator &) const
void	operator++ ()

Protected Member Functions
	iterator (container_t container)
void	seed ()

Protected Attributes
container_t	container
container_t::iterator	current {}

Detailed Description

template<typename container_t>
class dx::iterator< container_t >

range-for support shared by every dxd type whose elements aren't already kept in an STL container of their own (dx::key_value_tree, cf::data, cf::dictionary, cf::array): a derived_t populates container_t however it needs to - a single existing conversion, or an explicit per-element loop - in its own constructor, then calls seed() once population is complete; operator++()/operator!=() forward to container_t's own iterator from then on. operator*() stays derived_t's own: what it should return (a plain element, const or not) differs per user, from cf::data's read-only bytes to dx::key_value_tree's mutable, further-navigable child node.

derived_t declares its own typedef dx::iterator<container_t> super; (the usual convention throughout this codebase) - since derived_t is itself always named iterator too (matching container_t::iterator), routing every access through that super typedef, rather than this class' own injected name, is what keeps derived_t's base-init/seed()/current unambiguous.

container_t is a protected member, not a base - derived_t reaches it as super::container. from its own constructor, avoiding a real Clang bug where a protected std::vector<X> base gets access-checked against an unrelated std::vector<Y> elsewhere in the same instantiation stack. This member shadows any same-named container type alias a derived_t's own enclosing class declares; qualify those as enclosing_t::container.