The boost documentation recommends implementing iterator_core_access methods as private static members and then making the class a friend of classes derived from iterator_facade. Why is this preferred to the approach of making iterator_core_access a private base of iterator_facade? Rob.
"Robert Jones" <robertgbjones@gmail.com> writes:
The boost documentation recommends implementing iterator_core_access methods as private static members
No, not really. It just recommends implementing private nonstatic member functions with similar signatures to the static member functions used by iterator_core_access. Incidentally, you shouldn't be looking at those static member functions. They're not documented for a reason: the interface to iterator_core_access is an implementation detail of the library :)
and then making the class a friend of classes derived from iterator_facade.
Why is this preferred to the approach of making iterator_core_access a private base of iterator_facade?
Your suggestion doesn't make any sense to me: the recommendation is for users of iterator_facade, who don't get to control its base classes. Maybe you meant to suggest making iterator_core_access a private base of the iterator class derived from iterator_facade? That wouldn't help, as we're not overriding virtual functions. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
David Abrahams -
Robert Jones