Hi, Here is the input_iterator_facade template (similar in nature to Vladimir's eof_iterator ) I am using in Boost.Test development: namespace detail { template<typename T> struct value_type_ident { typedef T value_type; }; template<typename T> struct ref_type_ident { typedef T reference; }; } // namespace detail template< typename ImplPolicy, typename Derived = mpl::void_, typename ValueType = mpl::void_, typename Reference = mpl::void_> class input_iterator_facade : public iterator_facade< typename mpl::if_<mpl::is_void_<Derived>,input_iterator_facade<ImplPolicy>,Derived>:: type, typename mpl::if_<mpl::is_void_<ValueType>,ImplPolicy,detail::value_type_ident<ValueT ype> >::type::value_type, forward_traversal_tag, typename mpl::if_<mpl::is_void_<Reference>,ImplPolicy,detail::ref_type_ident<Referenc e> >::type::reference> { public: // Constructor explicit input_iterator_facade( ImplPolicy const& p = ImplPolicy() ) : m_policy( p ) { m_valid = m_policy.initialize(); increment(); } //!! copy constructor/assignment - should we make rhs invalid after copy?? //!! do we need reset method? protected: // provide access to the derived // Data members ImplPolicy m_policy; private: friend class iterator_core_access; // iterator facade interface implementation void increment() { if( m_valid ) m_valid = m_policy.get(); } bool equal( input_iterator_facade const& rhs ) const { return !m_valid && !rhs.m_valid || m_valid && rhs.m_valid && m_policy.equal( rhs.m_policy ); } reference dereference() const { return m_policy.dereference( m_valid ); } // Data members bool m_valid; }; See full versions with extra comments here: http://tinyurl.com/2x69z There is one specific iterator implemented that used this template located in the same directory (more coming). I actually combine new CRTP and old policy technique here, for later allows me to implement more functionality in common code. Is there interest in adding this to the family of iterator helpers? Or could I move it in boost namespace for convenience? Gennadiy.