Converting from const to non-const with iterator_adaptor
Hi, I'm stuck trying to use iterator_adaptor from the CVS head. I simply want to derive a non-const iterator from a const one derived from iterator_facade, as shown in the code below. When I compile it with VC7.1, the line marked "/* *ERROR* */" generates one of those impenetratable error messages that starts with: cannot convert from 'const Node' to 'boost::iterator_facade<Derived,Value,CategoryOrTraversal,Reference,Differen ce>::reference' If I delete that line, so the default is used, dereferencing a non-const iterator returns a const Node. This seems such a simple requirement that there must be an easy way to do it. What am I doing wrong? Thanks, Keith MacDonald /* ========================= Code Begins ========================= */ #include <boost/iterator/iterator_facade.hpp> #include <boost/iterator/iterator_adaptor.hpp> class Node { // ... // Iteration: public: class iterator; class const_iterator; // Read-only, bidirectional iterator: typedef boost::iterator_facade< const_iterator, const Node, std::bidirectional_iterator_tag
boost_const_iterator;
class const_iterator : public boost_const_iterator { public: const_iterator() {} const_iterator(const iterator& it) : m_pNode(it.base().m_pNode) {} explicit const_iterator(const Node* pNode) : m_pNode(pNode) {} friend class iterator; friend class boost::iterator_core_access; private: // Interface required by iterator_facade: reference dereference() const { return *m_pNode; } void increment() { m_pNode = m_pNode->next(); } void decrement() { m_pNode = m_pNode->prev(); } bool equal(const_iterator it) const { return m_pNode == it.m_pNode; } protected: const Node* m_pNode; }; // Read-write, bidirectional iterator, // adapted from const_iterator: typedef boost::iterator_adaptor< iterator, const_iterator, Node /* *ERROR* */
iterator_base;
class iterator : public iterator_base { public: iterator() {} explicit iterator(Node* pNode) : iterator_base(const_iterator(pNode)) {} }; const_iterator begin() const { return const_iterator(m_pChild); } const_iterator end() const { return const_iterator(NULL); } iterator begin() { return iterator(m_pChild); } iterator end() { return iterator(NULL); } private: Node* m_pChild; Node* m_pPrev; Node* m_pNext; }; /* ========================= Code Ends ========================= */
"Keith MacDonald" <boost@mailclan.net> writes:
Hi,
I'm stuck trying to use iterator_adaptor from the CVS head. I simply want to derive a non-const iterator from a const one derived from iterator_facade, as shown in the code below.
Answer: don't do that. Making iterators by derivation from other iterators is almost always an error (and in your case also: for example the return type of operator++ is wrong on the derived iterator). Make a new constant iterator type with iterator_facade. If you do it right, it will interoperate properly with your mutable iterator.
When I compile it with VC7.1, the line marked "/* *ERROR* */" generates one of those impenetratable error messages that starts with:
cannot convert from 'const Node' to 'boost::iterator_facade<Derived,Value,CategoryOrTraversal,Reference,Differen ce>::reference'
Compile with GCC; you'll get better error messages. The type 'boost::iterator_facade<Derived,Value,CategoryOrTraversal,Reference,Difference>::reference' is almost certainly 'Node&', which can't be bound to a 'const Node'.
If I delete that line, so the default is used, dereferencing a non-const iterator returns a const Node. This seems such a simple requirement that there must be an easy way to do it. What am I doing wrong?
Looks like a job for iterator_adaptor: // untested template <class V> struct iter : boost::iterator_adaptor<iter<V>, V*, V, boost::bidirectional_traversal_tag> { typedef boost::iterator_adaptor<iter<V>, V*, V, boost::bidirectional_traversal_tag> super; iter() {} template <class V2> iter(iter<V2> x, boost::enable_if_convertible<V2*,V*>::type* = 0) : super(x.base()) friend class iterator; friend class boost::iterator_core_access; private: void increment() { base() = base()->next(); } void decrement() { base() = base()->prev(); } }; typedef iter<Node> iterator; typedef iter<Node const> const_iterator; HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com
I may have misunderstood the purpose of boost::iterator: I was expecting it to make it easy to add standard conforming iterators to any container, but the complexity of the proposed solution, (using iterator_adaptor, which I can't get to compile), is making me doubt that. In an earlier release of the library, I was able to declare the const_iterator using iterator_facade, then simply adapt it to a non-const iterator using iterator_adaptor, as shown in my original posting. I've not followed the discussions that led up to the current implementation, so don't know what its advantages are, but if it can't provide a simple solution to the simplest case, has something important been thrown out with the bath water? My working solution is now to use iterator_facade to declare instances of const_iterator and iterator, which are independent of each other, except that a const_iterator can be constructed from an iterator. Instinctively, this does not seem to the intended way to do it, but it would probably be quicker to write the iterators from scratch than work that out from the documentation. Can I make a plea for an example to be included with the library, which shows how best to add plain vanilla iterators to a container class? Thanks, Keith MacDonald "David Abrahams" <dave@boost-consulting.com> wrote in message news:u65frftpp.fsf@boost-consulting.com...
Looks like a job for iterator_adaptor:
// untested template <class V> struct iter : boost::iterator_adaptor<iter<V>, V*, V,
boost::bidirectional_traversal_tag>
{ typedef boost::iterator_adaptor<iter<V>, V*, V, boost::bidirectional_traversal_tag> super;
iter() {}
template <class V2> iter(iter<V2> x, boost::enable_if_convertible<V2*,V*>::type* = 0) : super(x.base())
friend class iterator; friend class boost::iterator_core_access;
private: void increment() { base() = base()->next(); }
void decrement() { base() = base()->prev(); } };
typedef iter<Node> iterator; typedef iter<Node const> const_iterator;
HTH,
-- Dave Abrahams Boost Consulting www.boost-consulting.com
"Keith MacDonald" <boost@mailclan.net> writes:
I may have misunderstood the purpose of boost::iterator
Do you mean the Boost.Iterator library? There's no boost::iterator component.
I was expecting it to make it easy to add standard conforming iterators to any container
Containers are sort of irrelevant. It makes it easy to build conforming iterators and adapt existing iterators.
but the complexity of the proposed solution
?? it's way simpler than what you posted ??
(using iterator_adaptor, which I can't get to compile)
<sigh> Fine, here's a complete, compilable example. #include <boost/iterator/iterator_adaptor.hpp> struct Node { Node* next(); Node* prev(); Node const* next() const; Node const* prev() const; }; template <class V> struct iter : boost::iterator_adaptor<iter<V>, V*, V, boost::bidirectional_traversal_tag> { typedef boost::iterator_adaptor<iter<V>, V*, V, boost::bidirectional_traversal_tag> super; iter() {} template <class V2> iter(iter<V2> const& x, typename boost::enable_if_convertible<V2*,V*>::type* = 0) : super(x.base()) {} friend class boost::iterator_core_access; private: void increment() { base() = base()->next(); } void decrement() { base() = base()->prev(); } }; int main() { typedef iter<Node> iterator; typedef iter<Node const> const_iterator; iterator x; const_iterator y; y = x; }
is making me doubt that. In an earlier release of the library, I was able to declare the const_iterator using iterator_facade
You still can, but you have to do more work with iterator_facade. Why declare the dereference member if you don't need to?
then simply adapt it to a non-const iterator using iterator_adaptor, as shown in my original posting.
Is that what your posting was doing? And you think that's simpler than what I did above?
I've not followed the discussions that led up to the current implementation, so don't know what its advantages are, but if it can't provide a simple solution to the simplest case, has something important been thrown out with the bath water?
I don't know what you mean. There was no iterator_facade in any earlier design which was substantially different from what's there now.
My working solution is now to use iterator_facade to declare instances of const_iterator and iterator, which are independent of each other, except that a const_iterator can be constructed from an iterator. Instinctively, this does not seem to the intended way to do it, but it would probably be quicker to write the iterators from scratch than work that out from the documentation.
We're working on the docs; we apologize for the delay.
Can I make a plea for an example to be included with the library, which shows how best to add plain vanilla iterators to a container class?
OK. What do you mean by "plain vanilla?" -- Dave Abrahams Boost Consulting www.boost-consulting.com
You have proposed a very elegant solution, but I would defy anyone who does not understand the library inside out to arrive at that solution. The documentation (iterator/doc/index.html#iterator-facade-and-adaptor) states: "It is common to define a new iterator which behaves like another iterator, but which modifies some aspect of its behavior. For that purpose, the library supplies the iterator_adaptor class template, which is specially designed to take advantage of as much of the underlying iterator's behavior as possible." In this case, I can't see what the underlying iterator is, so don't understand how iteration can proceed. For example, if you add the statement "++x;" to your example, it fails to compile. To return to my point about the purpose of a software library, my approach is generally to ask if it will allow me to implement code more quickly and reliably than without it. I got to the point of thinking, I've now got to implement a straightforward iterator, sigh, so will the boost library help me? I didn't expect to have to develop a deep understanding of template metaprogramming and the curiously recurring template pattern, before I could move on. Hence my plea for an example of a plain vanilla iterator, by which I meant something similar to those used for the std library containers. That would make a much more satisfactory introduction than trying to plough through the impenetrable documentation. Thanks for your time and, possibly, for an extremely useful library! Keith MacDonald "David Abrahams" <dave@boost-consulting.com> wrote in message news:u4qvatli4.fsf@boost-consulting.com...
"Keith MacDonald" <boost@mailclan.net> writes:
I may have misunderstood the purpose of boost::iterator
Do you mean the Boost.Iterator library? There's no boost::iterator component.
I was expecting it to make it easy to add standard conforming iterators to any container
Containers are sort of irrelevant. It makes it easy to build conforming iterators and adapt existing iterators.
but the complexity of the proposed solution
?? it's way simpler than what you posted ??
(using iterator_adaptor, which I can't get to compile)
<sigh> Fine, here's a complete, compilable example.
#include <boost/iterator/iterator_adaptor.hpp>
struct Node { Node* next(); Node* prev(); Node const* next() const; Node const* prev() const; };
template <class V> struct iter : boost::iterator_adaptor<iter<V>, V*, V, boost::bidirectional_traversal_tag> { typedef boost::iterator_adaptor<iter<V>, V*, V, boost::bidirectional_traversal_tag> super;
iter() {}
template <class V2> iter(iter<V2> const& x, typename boost::enable_if_convertible<V2*,V*>::type* = 0) : super(x.base()) {}
friend class boost::iterator_core_access;
private: void increment() { base() = base()->next(); }
void decrement() { base() = base()->prev(); } };
int main() { typedef iter<Node> iterator; typedef iter<Node const> const_iterator;
iterator x; const_iterator y; y = x; }
is making me doubt that. In an earlier release of the library, I was able to declare the const_iterator using iterator_facade
You still can, but you have to do more work with iterator_facade. Why declare the dereference member if you don't need to?
then simply adapt it to a non-const iterator using iterator_adaptor, as shown in my original posting.
Is that what your posting was doing? And you think that's simpler than what I did above?
I've not followed the discussions that led up to the current implementation, so don't know what its advantages are, but if it can't provide a simple solution to the simplest case, has something important been thrown out with the bath water?
I don't know what you mean. There was no iterator_facade in any earlier design which was substantially different from what's there now.
My working solution is now to use iterator_facade to declare instances of const_iterator and iterator, which are independent of each other, except that a const_iterator can be constructed from an iterator. Instinctively, this does not seem to the intended way to do it, but it would probably be quicker to write the iterators from scratch than work that out from the documentation.
We're working on the docs; we apologize for the delay.
Can I make a plea for an example to be included with the library, which shows how best to add plain vanilla iterators to a container class?
OK. What do you mean by "plain vanilla?"
-- Dave Abrahams Boost Consulting www.boost-consulting.com
"Keith MacDonald" <boost@mailclan.net> writes:
You have proposed a very elegant solution, but I would defy anyone who does not understand the library inside out to arrive at that solution. The documentation (iterator/doc/index.html#iterator-facade-and-adaptor) states:
We're working on the docs. That document is the standards proposal, but the Boost (user-level) docs aren't complete yet.
"It is common to define a new iterator which behaves like another iterator, but which modifies some aspect of its behavior. For that purpose, the library supplies the iterator_adaptor class template, which is specially designed to take advantage of as much of the underlying iterator's behavior as possible."
In this case, I can't see what the underlying iterator is, so don't understand how iteration can proceed.
I quote: The iterator_adaptor class template adapts some Base 3 type to create a new iterator. Instantiations of iterator_adaptor are derived from a corresponding instantiation of iterator_facade and implement the core behaviors in terms of the Base type. In essence, iterator_adaptor merely forwards all operations to an instance of the Base type, which it stores as a member. [3] The term "Base" here does not refer to a base class and is not meant to imply the use of derivation. We have followed the lead of the standard library, which provides a base() function to access the underlying iterator object of a reverse_iterator adaptor. The user of iterator_adaptor creates a class derived from an instantiation of iterator_adaptor and then selectively redefines some of the core member functions described in the table above. The Base type need not meet the full requirements for an iterator. It ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ need only support the operations used by the core interface functions of iterator_adaptor that have not been redefined in the user's derived class.
For example, if you add the statement "++x;" to your example, it fails to compile.
Umm, sorry. I whipped that one off without too much testing. I've enclosed a fixed one.
To return to my point about the purpose of a software library, my approach is generally to ask if it will allow me to implement code more quickly and reliably than without it. I got to the point of thinking, I've now got to implement a straightforward iterator, sigh, so will the boost library help me? I didn't expect to have to develop a deep understanding of template metaprogramming and the curiously recurring template pattern, before I could move on.
Why would you need to develop either of those? You just follow the formula.
Hence my plea for an example of a plain vanilla iterator, by which I meant something similar to those used for the std library containers.
I'm sorry, I need you to be more specific. Is the example of your node iterator good enough? -- Dave Abrahams Boost Consulting www.boost-consulting.com
That's just what I needed! It makes much more sense now that you have explained that iterator_adaptor adapts a base class, rather than an iterator, as originally documented. The concept is amazingly powerful, and now that I've cleared the first hurdle, I'm much more inclined to explore other uses. I've adapted your example to implement begin() and end() methods, with a little test, and have attached the code. I hope you can include such an example with the library. Thanks again for your help. Keith MacDonald "David Abrahams" <dave@boost-consulting.com> wrote in message news:uwu85i0my.fsf@boost-consulting.com...
"Keith MacDonald" <boost@mailclan.net> writes:
You have proposed a very elegant solution, but I would defy anyone who does not understand the library inside out to arrive at that solution. The documentation (iterator/doc/index.html#iterator-facade-and-adaptor) states:
We're working on the docs. That document is the standards proposal, but the Boost (user-level) docs aren't complete yet.
"It is common to define a new iterator which behaves like another iterator, but which modifies some aspect of its behavior. For that purpose, the library supplies the iterator_adaptor class template, which is specially designed to take advantage of as much of the underlying iterator's behavior as possible."
In this case, I can't see what the underlying iterator is, so don't understand how iteration can proceed.
I quote:
The iterator_adaptor class template adapts some Base 3 type to create a new iterator. Instantiations of iterator_adaptor are derived from a corresponding instantiation of iterator_facade and implement the core behaviors in terms of the Base type. In essence, iterator_adaptor merely forwards all operations to an instance of the Base type, which it stores as a member.
[3] The term "Base" here does not refer to a base class and is not meant to imply the use of derivation. We have followed the lead of the standard library, which provides a base() function to access the underlying iterator object of a reverse_iterator adaptor.
The user of iterator_adaptor creates a class derived from an instantiation of iterator_adaptor and then selectively redefines some of the core member functions described in the table above. The Base type need not meet the full requirements for an iterator. It ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ need only support the operations used by the core interface functions of iterator_adaptor that have not been redefined in the user's derived class.
For example, if you add the statement "++x;" to your example, it fails to compile.
Umm, sorry. I whipped that one off without too much testing. I've enclosed a fixed one.
---------------------------------------------------------------------------- ----
To return to my point about the purpose of a software library, my approach is generally to ask if it will allow me to implement code more quickly and reliably than without it. I got to the point of thinking, I've now got to implement a straightforward iterator, sigh, so will the boost library help me? I didn't expect to have to develop a deep understanding of template metaprogramming and the curiously recurring template pattern, before I could move on.
Why would you need to develop either of those? You just follow the formula.
Hence my plea for an example of a plain vanilla iterator, by which I meant something similar to those used for the std library containers.
I'm sorry, I need you to be more specific. Is the example of your node iterator good enough?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
---------------------------------------------------------------------------- ----
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
begin 666 baz2.cpp M+R\@8F%Z,BYC<' Z($)I9&ER96-T:6]N86P@:71E<F%T;W(@97AA;7!L92X- M"B\O(%1O(&)U:6QD('=I=&@@35-60SH@8VP@+45(<V,@+4E<0U937&)O;W-T M(&)A>C(N8W!P#0H-"B-I;F-L=61E(#QI;W-T<F5A;3X-"B-I;F-L=61E(#QB M;V]S="]I=&5R871O<B]I=&5R871O<E]A9&%P=&]R+FAP<#X-"@T*+R\@:71E M<B!C86X@8F4@=7-E9"!T;R!D96-L87)E('-T86YD87)D+"!B:61I<F5C=&EO M;F%L(&ET97)A=&]R<PT*+R\@9F]R(&%N>2!C;&%S<R!6+"!W:&EC:"!H87,@ M<')E=B@I(&%N9"!N97AT*"D@;65M8F5R<RX-"@T*=&5M<&QA=&4@/&-L87-S M(%8^#0IS=')U8W0@:71E<@T*"3H@8F]O<W0Z.FET97)A=&]R7V%D87!T;W(\ M:71E<CQ6/BP@5BHL(%8L(&)O;W-T.CIB:61I<F5C=&EO;F%L7W1R879E<G-A M;%]T86<^#0I[#0H)='EP961E9@T*"0EB;V]S=#HZ:71E<F%T;W)?861A<'1O M<CQI=&5R/%8^+"!6*BP@5BP@8F]O<W0Z.F)I9&ER96-T:6]N86Q?=')A=F5R M<V%L7W1A9SX-"@ES=7!E<CL-"@T*"6ET97(H*2![?0T*#0H)97AP;&EC:70@ M:71E<BA6*B!N*0T*"0DZ('-U<&5R*&XI#0H)>WT-"@T*"71E;7!L871E(#QC M;&%S<R!6,CX-"@EI=&5R*&ET97(\5C(^(&-O;G-T)B!X+"!T>7!E;F%M92!B M;V]S=#HZ96YA8FQE7VEF7V-O;G9E<G1I8FQE/%8R*BQ6*CXZ.G1Y<&4J(#T@ M,"D-"@D).B!S=7!E<BAX+F)A<V4H*2D-"@E[?0T*#0H)9G)I96YD(&-L87-S M(&)O;W-T.CII=&5R871O<E]C;W)E7V%C8V5S<SL-"@T*<')I=F%T93H-"@EV M;VED(&EN8W)E;65N="@I#0H)>R!B87-E7W)E9F5R96YC92@I(#T@8F%S92@I M+3YN97AT*"D[('T-"@T*"79O:60@9&5C<F5M96YT*"D-"@E[(&)A<V5?<F5F M97)E;F-E*"D@/2!B87-E*"DM/G!R978H*3L@?0T*?3L-"@T*+R\@8VQA<W,@ M3F]D92!U<V5S(&ET97(@=&\@:6UP;&5M96YT(&ET97)A=&EO;B!O=F5R(&$@ M9&]U8FQY(&QI;FME9"!L:7-T+@T*8VQA<W,@3F]D90T*>PT*<'5B;&EC.@T* M"4YO9&4H:6YT(&Y686PI#0H)"3H@;5]N5F%L*&Y686PI+"!M7W!.97AT*$Y5 M3$PI+"!M7W!0<F5V*$Y53$PI#0H)>WT-"@T*"79O:60@87!P96YD*$YO9&4J M('!.;V1E*0T*"7L@;5]P3F5X=" ]('!.;V1E.R!P3F]D92T^;5]P4')E=B ] M('1H:7,[('T-"@T*"4YO9&4@8V]N<W0J('!R978H*2!C;VYS= T*"7L@<F5T M=7)N(&U?<%!R978[('T-"@T*"4YO9&4J('!R978H*0T*"7L@<F5T=7)N(&U? M<%!R978[('T-"@T*"4YO9&4@8V]N<W0J(&YE>'0H*2!C;VYS= T*"7L@<F5T M=7)N(&U?<$YE>'0[('T-"@T*"4YO9&4J(&YE>'0H*0T*"7L@<F5T=7)N(&U? M<$YE>'0[('T-"@T*"6EN="!V86QU92@I(&-O;G-T#0H)>R!R971U<FX@;5]N M5F%L.R!]#0H-"B\O($ET97)A=&EO;CH-"@ET>7!E9&5F(&ET97(\3F]D93X@ M:71E<F%T;W([#0H)='EP961E9B!I=&5R/$YO9&4@8V]N<W0^(&-O;G-T7VET M97)A=&]R.PT*#0H)8V]N<W1?:71E<F%T;W(@8F5G:6XH*2!C;VYS= T*"7L- M"@D)<F5T=7)N(&-O;G-T7VET97)A=&]R*'1H:7,I.PT*"7T-"@T*"6-O;G-T M7VET97)A=&]R(&5N9"@I(&-O;G-T#0H)>PT*"0ER971U<FX@8V]N<W1?:71E M<F%T;W(H3E5,3"D[#0H)?0T*#0H):71E<F%T;W(@8F5G:6XH*0T*"7L-"@D) M<F5T=7)N(&ET97)A=&]R*'1H:7,I.PT*"7T-"@T*"6ET97)A=&]R(&5N9"@I M#0H)>PT*"0ER971U<FX@:71E<F%T;W(H3E5,3"D[#0H)?0T*#0IP<FEV871E M.@T*"4YO9&4J"6U?<$YE>'0[#0H)3F]D92H);5]P4')E=CL-"@EI;G0)"6U? M;E9A;#L-"GT[#0H-"B\O(%1E<W0@=&AA="!I=&5R871I;VX@=V]R:W,@*&EG M;F]R:6YG(&UE;6]R>2!L96%K<RDN#0H-"FEN="!M86EN*"D-"GL-"B @("!. M;V1E( ER;V]T*#$I.PT*(" @($YO9&4J"7!.;V1E(#T@;F5W($YO9&4H,BD[ M#0H-"B @("!R;V]T+F%P<&5N9"AP3F]D92D[#0H@(" @<$YO9&4M/F%P<&5N M9"AN97<@3F]D92@S*2D[#0H-"B @("!.;V1E.CIC;VYS=%]I=&5R871O<B!I M=$5N9" ](')O;W0N96YD*"D[#0H-"@DO+R!/=71P=70@<VAO=6QD(&)E.B Q M(#(@,PT*(" @(&9O<B H3F]D93HZ:71E<F%T;W(@:70@/2!R;V]T+F)E9VEN M*"D[(&ET("$](&ET16YD.R K*VET*0T*"0ES=&0Z.F-O=70@/#P@*"II="DN H=F%L=64H*2 \/"!S=&0Z.F5N9&P[#0H-"@ER971U<FX@,#L-"GT-"@`` ` end
"Keith MacDonald" <boost@mailclan.net> writes:
That's just what I needed! It makes much more sense now that you have explained that iterator_adaptor adapts a base class, rather than an iterator, as originally documented.
I was quoting the same documentation you referred to.
The concept is amazingly powerful, and now that I've cleared the first hurdle, I'm much more inclined to explore other uses.
Glad to know it's useful.
I've adapted your example to implement begin() and end() methods, with a little test, and have attached the code. I hope you can include such an example with the library.
I'd love to. If I'm to use your code wholesale, I'll need you to add the standard boost copyright and license reference. -- Dave Abrahams Boost Consulting www.boost-consulting.com
I was quoting the same documentation you referred to.
OK, but my quote came from the front page (index.html), so I read that first. Perhaps that section should be rewritten.
I'd love to. If I'm to use your code wholesale, I'll need you to add the standard boost copyright and license reference.
I've done that, and attach the new source. However, I hereby relinquish all rights over baz2.cpp, so feel free to do whatever you like with it. When I attempted to integrate the iterators with my actual code, I hit a problem that I don't know how to resolve with iterator_facade. To illustrate it, I've modified the example code and attach it as baz3.cpp. Now, Node is an abstract base class, and DerivedNode is instantiated. Compiling it results in the following error: \CVS\boost\boost\iterator\iterator_facade.hpp(389) : error C2259: 'Node' : cannot instantiate abstract class due to following members: 'int Node::getInfo(void) const' : pure virtual function was not defined Can your technique be used in such contexts? Thanks, Keith MacDonald begin 666 baz2.cpp M+R\@8F%Z,BYC<' Z($)I9&ER96-T:6]N86P@:71E<F%T;W(@97AA;7!L92X- M"B\J#0I";V]S="!3;V9T=V%R92!,:6-E;G-E("T@5F5R<VEO;B Q+C @+2!! M=6=U<W0@,3=T:"P@,C P,PT*#0I097)M:7-S:6]N(&ES(&AE<F5B>2!G<F%N M=&5D+"!F<F5E(&]F(&-H87)G92P@=&\@86YY('!E<G-O;B!O<B!O<F=A;FEZ M871I;VX-"F]B=&%I;FEN9R!A(&-O<'D@;V8@=&AE('-O9G1W87)E(&%N9"!A M8V-O;7!A;GEI;F<@9&]C=6UE;G1A=&EO;B!C;W9E<F5D(&)Y#0IT:&ES(&QI M8V5N<V4@*'1H92 B4V]F='=A<F4B*2!T;R!U<V4L(')E<')O9'5C92P@9&ES M<&QA>2P@9&ES=')I8G5T92P-"F5X96-U=&4L(&%N9"!T<F%N<VUI="!T:&4@ M4V]F='=A<F4L(&%N9"!T;R!P<F5P87)E(&1E<FEV871I=F4@=V]R:W,@;V8@ M=&AE#0I3;V9T=V%R92P@86YD('1O('!E<FUI="!T:&ER9"UP87)T:65S('1O M('=H;VT@=&AE(%-O9G1W87)E(&ES(&9U<FYI<VAE9"!T;PT*9&\@<V\L(&%L M;"!S=6)J96-T('1O('1H92!F;VQL;W=I;F<Z#0H-"E1H92!C;W!Y<FEG:'0@ M;F]T:6-E<R!I;B!T:&4@4V]F='=A<F4@86YD('1H:7,@96YT:7)E('-T871E M;65N="P@:6YC;'5D:6YG#0IT:&4@86)O=F4@;&EC96YS92!G<F%N="P@=&AI M<R!R97-T<FEC=&EO;B!A;F0@=&AE(&9O;&QO=VEN9R!D:7-C;&%I;65R+ T* M;75S="!B92!I;F-L=61E9"!I;B!A;&P@8V]P:65S(&]F('1H92!3;V9T=V%R M92P@:6X@=VAO;&4@;W(@:6X@<&%R="P@86YD#0IA;&P@9&5R:79A=&EV92!W M;W)K<R!O9B!T:&4@4V]F='=A<F4L('5N;&5S<R!S=6-H(&-O<&EE<R!O<B!D M97)I=F%T:79E#0IW;W)K<R!A<F4@<V]L96QY(&EN('1H92!F;W)M(&]F(&UA M8VAI;F4M97AE8W5T86)L92!O8FIE8W0@8V]D92!G96YE<F%T960@8GD-"F$@ M<V]U<F-E(&QA;F=U86=E('!R;V-E<W-O<BX-"@T*5$A%(%-/1E1705)%($E3 M(%!23U9)1$5$(")!4R!)4R(L(%=)5$A/550@5T%24D%.5%D@3T8@04Y9($M) M3D0L($584%)%4U,@3U(-"DE-4$Q)140L($E.0TQ51$E.1R!"550@3D]4($Q) M34E4140@5$\@5$A%(%=!4E)!3E1)15,@3T8@34520TA!3E1!0DE,2519+ T* M1DE43D534R!&3U(@02!005)424-53$%2(%!54E!/4T4L(%1)5$Q%($%.1"!. M3TXM24Y&4DE.1T5-14Y4+B!)3B!.3R!%5D5.5 T*4TA!3$P@5$A%($-/4%E2 M24=(5"!(3TQ$15)3($]2($%.64].12!$25-44DE"551)3D<@5$A%(%-/1E17 M05)%($)%($Q)04),10T*1D]2($%.62!$04U!1T53($]2($]42$52($Q)04)) M3$E462P@5TA%5$A%4B!)3B!#3TY44D%#5"P@5$]25"!/4B!/5$A%4E=)4T4L M#0I!4DE324Y'($923TTL($]55"!/1B!/4B!)3B!#3TY.14-424].(%=)5$@@ M5$A%(%-/1E1705)%($]2(%1(12!54T4@3U(@3U1(15(-"D1%04Q)3D=3($E. M(%1(12!33T945T%212X-"BHO#0HO+R!4;R!B=6EL9"!W:71H($U35D,Z(&-L M("U%2'-C("U)7$-64UQB;V]S="!B87HR+F-P< T*#0HC:6YC;'5D92 \:6]S M=')E86T^#0HC:6YC;'5D92 \8F]O<W0O:71E<F%T;W(O:71E<F%T;W)?861A M<'1O<BYH<' ^#0H-"B\O(&ET97(@8V%N(&)E('5S960@=&\@9&5C;&%R92!S M=&%N9&%R9"P@8FED:7)E8W1I;VYA;"!I=&5R871O<G,-"B\O(&9O<B!A;GD@ M8VQA<W,@5BP@=VAI8V@@:&%S('!R978H*2!A;F0@;F5X="@I(&UE;6)E<G,N M#0H-"G1E;7!L871E(#QC;&%S<R!6/@T*<W1R=6-T(&ET97(-"@DZ(&)O;W-T M.CII=&5R871O<E]A9&%P=&]R/&ET97(\5CXL(%8J+"!6+"!B;V]S=#HZ8FED M:7)E8W1I;VYA;%]T<F%V97)S86Q?=&%G/@T*>PT*"71Y<&5D968-"@D)8F]O M<W0Z.FET97)A=&]R7V%D87!T;W(\:71E<CQ6/BP@5BHL(%8L(&)O;W-T.CIB M:61I<F5C=&EO;F%L7W1R879E<G-A;%]T86<^#0H)<W5P97([#0H-"@EI=&5R M*"D@>WT-"@T*"65X<&QI8VET(&ET97(H5BH@;BD-"@D).B!S=7!E<BAN*0T* M"7M]#0H-"@ET96UP;&%T92 \8VQA<W,@5C(^#0H):71E<BAI=&5R/%8R/B!C M;VYS="8@>"P@='EP96YA;64@8F]O<W0Z.F5N86)L95]I9E]C;VYV97)T:6)L M93Q6,BHL5BH^.CIT>7!E*B ](# I#0H)"3H@<W5P97(H>"YB87-E*"DI#0H) M>WT-"@T*"69R:65N9"!C;&%S<R!B;V]S=#HZ:71E<F%T;W)?8V]R95]A8V-E M<W,[#0H-"G!R:79A=&4Z#0H)=F]I9"!I;F-R96UE;G0H*0T*"7L@8F%S95]R M969E<F5N8V4H*2 ](&)A<V4H*2T^;F5X="@I.R!]#0H-"@EV;VED(&1E8W)E M;65N="@I#0H)>R!B87-E7W)E9F5R96YC92@I(#T@8F%S92@I+3YP<F5V*"D[ M('T-"GT[#0H-"B\O(&-L87-S($YO9&4@=7-E<R!I=&5R('1O(&EM<&QE;65N M="!I=&5R871I;VX@;W9E<B!A(&1O=6)L>2!L:6YK960@;&ES="X-"F-L87-S M($YO9&4-"GL-"G!U8FQI8SH-"@E.;V1E*&EN="!N5F%L*0T*"0DZ(&U?;E9A M;"AN5F%L*2P@;5]P3F5X="A.54Q,*2P@;5]P4')E=BA.54Q,*0T*"7M]#0H- M"@EV;VED(&%P<&5N9"A.;V1E*B!P3F]D92D-"@E[(&U?<$YE>'0@/2!P3F]D M93L@<$YO9&4M/FU?<%!R978@/2!T:&ES.R!]#0H-"@E.;V1E(&-O;G-T*B!P M<F5V*"D@8V]N<W0-"@E[(')E='5R;B!M7W!0<F5V.R!]#0H-"@E.;V1E*B!P M<F5V*"D-"@E[(')E='5R;B!M7W!0<F5V.R!]#0H-"@E.;V1E(&-O;G-T*B!N M97AT*"D@8V]N<W0-"@E[(')E='5R;B!M7W!.97AT.R!]#0H-"@E.;V1E*B!N M97AT*"D-"@E[(')E='5R;B!M7W!.97AT.R!]#0H-"@EI;G0@=F%L=64H*2!C M;VYS= T*"7L@<F5T=7)N(&U?;E9A;#L@?0T*#0HO+R!)=&5R871I;VXZ#0H) M='EP961E9B!I=&5R/$YO9&4^(&ET97)A=&]R.PT*"71Y<&5D968@:71E<CQ. M;V1E(&-O;G-T/B!C;VYS=%]I=&5R871O<CL-"@T*"6-O;G-T7VET97)A=&]R M(&)E9VEN*"D@8V]N<W0-"@E[#0H)"7)E='5R;B!C;VYS=%]I=&5R871O<BAT M:&ES*3L-"@E]#0H-"@EC;VYS=%]I=&5R871O<B!E;F0H*2!C;VYS= T*"7L- M"@D)<F5T=7)N(&-O;G-T7VET97)A=&]R*$Y53$PI.PT*"7T-"@T*"6ET97)A M=&]R(&)E9VEN*"D-"@E[#0H)"7)E='5R;B!I=&5R871O<BAT:&ES*3L-"@E] M#0H-"@EI=&5R871O<B!E;F0H*0T*"7L-"@D)<F5T=7)N(&ET97)A=&]R*$Y5 M3$PI.PT*"7T-"@T*<')I=F%T93H-"@E.;V1E*@EM7W!.97AT.PT*"4YO9&4J M"6U?<%!R978[#0H):6YT"0EM7VY686P[#0I].PT*#0HO+R!497-T('1H870@ M:71E<F%T:6]N('=O<FMS("AI9VYO<FEN9R!M96UO<GD@;&5A:W,I+@T*#0II M;G0@;6%I;B@I#0I[#0H@(" @3F]D92 )<F]O="@Q*3L-"B @("!.;V1E*@EP M3F]D92 ](&YE=R!.;V1E*#(I.PT*#0H@(" @<F]O="YA<'!E;F0H<$YO9&4I M.PT*(" @('!.;V1E+3YA<'!E;F0H;F5W($YO9&4H,RDI.PT*#0H@(" @3F]D M93HZ8V]N<W1?:71E<F%T;W(@:71%;F0@/2!R;V]T+F5N9"@I.PT*#0H)+R\@ M3W5T<'5T('-H;W5L9"!B93H@,2 R(#,-"B @("!F;W(@*$YO9&4Z.FET97)A M=&]R(&ET(#T@<F]O="YB96=I;B@I.R!I=" A/2!I=$5N9#L@*RMI="D-"@D) M<W1D.CIC;W5T(#P\("@J:70I+G9A;'5E*"D@/#P@<W1D.CIE;F1L.PT*#0H) .<F5T=7)N(# [#0I]#0H` ` end begin 666 baz3.cpp M+R\@8F%Z,RYC<' Z($)I9&ER96-T:6]N86P@:71E<F%T;W(@97AA;7!L92P@ M=VET:"!A8G-T<F%C="!B87-E(&-L87-S+@T*+R\@5&\@8G5I;&0@=VET:"!- M4U9#.B!C;" M14AS8R M25Q#5E-<8F]O<W0@8F%Z,RYC<' -"@T*(VEN8VQU M9&4@/&EO<W1R96%M/@T*(VEN8VQU9&4@/&)O;W-T+VET97)A=&]R+VET97)A M=&]R7V%D87!T;W(N:'!P/@T*#0HO+R!I=&5R(&-A;B!B92!U<V5D('1O(&1E M8VQA<F4@<W1A;F1A<F0L(&)I9&ER96-T:6]N86P@:71E<F%T;W)S#0HO+R!F M;W(@86YY(&-L87-S(%8L('=H:6-H(&AA<R!P<F5V*"D@86YD(&YE>'0H*2!M M96UB97)S+@T*#0IT96UP;&%T92 \8VQA<W,@5CX-"G-T<G5C="!I=&5R#0H) M.B!B;V]S=#HZ:71E<F%T;W)?861A<'1O<CQI=&5R/%8^+"!6*BP@5BP@8F]O M<W0Z.F)I9&ER96-T:6]N86Q?=')A=F5R<V%L7W1A9SX-"GL-"@ET>7!E9&5F M#0H)"6)O;W-T.CII=&5R871O<E]A9&%P=&]R/&ET97(\5CXL(%8J+"!6+"!B M;V]S=#HZ8FED:7)E8W1I;VYA;%]T<F%V97)S86Q?=&%G/@T*"7-U<&5R.PT* M#0H):71E<B@I('M]#0H-"@EE>'!L:6-I="!I=&5R*%8J(&XI#0H)"3H@<W5P M97(H;BD-"@E[?0T*#0H)=&5M<&QA=&4@/&-L87-S(%8R/@T*"6ET97(H:71E M<CQ6,CX@8V]N<W0F('@L('1Y<&5N86UE(&)O;W-T.CIE;F%B;&5?:69?8V]N M=F5R=&EB;&4\5C(J+%8J/CHZ='EP92H@/2 P*0T*"0DZ('-U<&5R*'@N8F%S M92@I*0T*"7M]#0H-"@EF<FEE;F0@8VQA<W,@8F]O<W0Z.FET97)A=&]R7V-O M<F5?86-C97-S.PT*#0IP<FEV871E.@T*"79O:60@:6YC<F5M96YT*"D-"@E[ M(&)A<V5?<F5F97)E;F-E*"D@/2!B87-E*"DM/FYE>'0H*3L@?0T*#0H)=F]I M9"!D96-R96UE;G0H*0T*"7L@8F%S95]R969E<F5N8V4H*2 ](&)A<V4H*2T^ M<')E=B@I.R!]#0I].PT*#0HO+R!C;&%S<R!.;V1E('5S97,@:71E<B!T;R!I M;7!L96UE;G0@:71E<F%T:6]N(&]V97(@82!D;W5B;'D@;&EN:V5D(&QI<W0N M#0IC;&%S<R!.;V1E#0I[#0IP=6)L:6,Z#0H)3F]D92AI;G0@;E9A;"D-"@D) M.B!M7VY686PH;E9A;"DL(&U?<$YE>'0H3E5,3"DL(&U?<%!R978H3E5,3"D- M"@E[?0T*#0H)=FER='5A;"!^3F]D92@I#0H)>WT-"@T*"79O:60@87!P96YD M*$YO9&4J('!.;V1E*0T*"7L@;5]P3F5X=" ]('!.;V1E.R!P3F]D92T^;5]P M4')E=B ]('1H:7,[('T-"@T*"4YO9&4@8V]N<W0J('!R978H*2!C;VYS= T* M"7L@<F5T=7)N(&U?<%!R978[('T-"@T*"4YO9&4J('!R978H*0T*"7L@<F5T M=7)N(&U?<%!R978[('T-"@T*"4YO9&4@8V]N<W0J(&YE>'0H*2!C;VYS= T* M"7L@<F5T=7)N(&U?<$YE>'0[('T-"@T*"4YO9&4J(&YE>'0H*0T*"7L@<F5T M=7)N(&U?<$YE>'0[('T-"@T*"6EN="!V86QU92@I(&-O;G-T#0H)>R!R971U M<FX@;5]N5F%L.R!]#0H-"@EV:7)T=6%L(&EN="!G971);F9O*"D@8V]N<W0@ M/2 P.PT*#0HO+R!)=&5R871I;VXZ#0H)='EP961E9B!I=&5R/$YO9&4^(&ET M97)A=&]R.PT*"71Y<&5D968@:71E<CQ.;V1E(&-O;G-T/B!C;VYS=%]I=&5R M871O<CL-"@T*"6-O;G-T7VET97)A=&]R(&)E9VEN*"D@8V]N<W0-"@E[#0H) M"7)E='5R;B!C;VYS=%]I=&5R871O<BAT:&ES*3L-"@E]#0H-"@EC;VYS=%]I M=&5R871O<B!E;F0H*2!C;VYS= T*"7L-"@D)<F5T=7)N(&-O;G-T7VET97)A M=&]R*$Y53$PI.PT*"7T-"@T*"6ET97)A=&]R(&)E9VEN*"D-"@E[#0H)"7)E M='5R;B!I=&5R871O<BAT:&ES*3L-"@E]#0H-"@EI=&5R871O<B!E;F0H*0T* M"7L-"@D)<F5T=7)N(&ET97)A=&]R*$Y53$PI.PT*"7T-"@T*<')I=F%T93H- M"@E.;V1E*@EM7W!.97AT.PT*"4YO9&4J"6U?<%!R978[#0H):6YT"0EM7VY6 M86P[#0I].PT*#0IC;&%S<R!$97)I=F5D3F]D93H@<'5B;&EC($YO9&4-"GL- M"G!U8FQI8SH-"@E$97)I=F5D3F]D92AI;G0@;E9A;"D-"@D).B!.;V1E*&Y6 M86PI#0H)>WT-"@T*"79I<G1U86P@:6YT(&=E=$EN9F\H*2!C;VYS= T*"7L- M"@D)<F5T=7)N(#$R,SL-"@E]#0I].PT*#0HO+R!497-T('1H870@:71E<F%T M:6]N('=O<FMS("AI9VYO<FEN9R!M96UO<GD@;&5A:W,I+@T*#0II;G0@;6%I M;B@I#0I[#0H@(" @1&5R:79E9$YO9&4@"7)O;W0H,2D[#0H@(" @1&5R:79E M9$YO9&4J"7!.;V1E(#T@;F5W($1E<FEV961.;V1E*#(I.PT*#0H@(" @<F]O M="YA<'!E;F0H<$YO9&4I.PT*(" @('!.;V1E+3YA<'!E;F0H;F5W($1E<FEV M961.;V1E*#,I*3L-"@T*(" @($YO9&4Z.F-O;G-T7VET97)A=&]R(&ET16YD M(#T@<F]O="YE;F0H*3L-"@T*"2\O($]U='!U="!S:&]U;&0@8F4Z(#$@,B S M#0H@(" @9F]R("A.;V1E.CII=&5R871O<B!I=" ](')O;W0N8F5G:6XH*3L@ M:70@(3T@:71%;F0[("LK:70I#0H)"7-T9#HZ8V]U=" \/" H*FET*2YV86QU D92@I(#P\('-T9#HZ96YD;#L-"@T*"7)E='5R;B P.PT*?0T* ` end
"Keith MacDonald" <boost@mailclan.net> writes:
I've done that, and attach the new source. However, I hereby relinquish all rights over baz2.cpp, so feel free to do whatever you like with it.
When I attempted to integrate the iterators with my actual code, I hit a problem that I don't know how to resolve with iterator_facade. To illustrate it, I've modified the example code and attach it as baz3.cpp. Now, Node is an abstract base class, and DerivedNode is instantiated. Compiling it results in the following error:
\CVS\boost\boost\iterator\iterator_facade.hpp(389) : error C2259: 'Node' : cannot instantiate abstract class due to following members: 'int Node::getInfo(void) const' : pure virtual function was not defined
Can your technique be used in such contexts?
Very interesting case. The problem is that, when the iterator is not writable, operator[] returns an object of the iterator's value_type. In this case the value_type is abstract, so it can't be returned. This raises several problems that I can see. 1. Obviously, the library doesn't work for you. You can get around that by applying the enclosed patch to iterator_facade.hpp. We'll figure out the right long-term fix soon; this one might be it. 2. We have to re-think the readable iterator requirements if we want iterators over abstract types to be legal. My feeling is that the requirement should be that *a is convertible to value_type const&. 3. Your iterator isn't a legal random access iterator, because the random access iterator requirements say that a[n] must be convertible to value_type. You can't convert anything to value_type in this case, since it can't be constructed. I think this is a defect in the current standard, and will submit a DR. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Your patch solves my immediate problem, thanks. Fortunately, both the classes that I need iterators for only require bidirectional semantics, so the random access issue does not arise, but thanks for pointing it out. Keith MacDonald "David Abrahams" <dave@boost-consulting.com> wrote in message news:uoetfa7th.fsf_-_@boost-consulting.com...
"Keith MacDonald" <boost@mailclan.net> writes:
I've done that, and attach the new source. However, I hereby relinquish all rights over baz2.cpp, so feel free to do whatever you like with it.
When I attempted to integrate the iterators with my actual code, I hit a problem that I don't know how to resolve with iterator_facade. To illustrate it, I've modified the example code and attach it as baz3.cpp. Now, Node is an abstract base class, and DerivedNode is instantiated. Compiling it results in the following error:
\CVS\boost\boost\iterator\iterator_facade.hpp(389) : error C2259: 'Node' : cannot instantiate abstract class due to following members: 'int Node::getInfo(void) const' : pure virtual function was not defined
Can your technique be used in such contexts?
Very interesting case. The problem is that, when the iterator is not writable, operator[] returns an object of the iterator's value_type. In this case the value_type is abstract, so it can't be returned.
This raises several problems that I can see.
1. Obviously, the library doesn't work for you. You can get around that by applying the enclosed patch to iterator_facade.hpp. We'll figure out the right long-term fix soon; this one might be it.
2. We have to re-think the readable iterator requirements if we want iterators over abstract types to be legal. My feeling is that the requirement should be that *a is convertible to value_type const&.
3. Your iterator isn't a legal random access iterator, because the random access iterator requirements say that a[n] must be convertible to value_type. You can't convert anything to value_type in this case, since it can't be constructed. I think this is a defect in the current standard, and will submit a DR.
---------------------------------------------------------------------------- ----
-- Dave Abrahams Boost Consulting www.boost-consulting.com
---------------------------------------------------------------------------- ----
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
"Keith MacDonald" <boost@mailclan.net> writes:
I was quoting the same documentation you referred to.
OK, but my quote came from the front page (index.html), so I read that first. Perhaps that section should be rewritten.
I realize the measure of docs is in their effectiveness, but do you really think there's anything wrong with painting with a broad brush on the main page and then providing detailed revision in specific docs?
I'd love to. If I'm to use your code wholesale, I'll need you to add the standard boost copyright and license reference.
I've done that, and attach the new source. However, I hereby relinquish all rights over baz2.cpp, so feel free to do whatever you like with it.
Thanks.
When I attempted to integrate the iterators with my actual code, I hit a problem that I don't know how to resolve with iterator_facade. To illustrate it, I've modified the example code and attach it as baz3.cpp. Now, Node is an abstract base class, and DerivedNode is instantiated. Compiling it results in the following error:
\CVS\boost\boost\iterator\iterator_facade.hpp(389) : error C2259: 'Node' : cannot instantiate abstract class due to following members: 'int Node::getInfo(void) const' : pure virtual function was not defined
Can your technique be used in such contexts?
Thanks, Keith MacDonald
-- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7k021gic.fsf@boost-consulting.com...
I realize the measure of docs is in their effectiveness, but do you really think there's anything wrong with painting with a broad brush on the main page and then providing detailed revision in specific docs? --
Only if the broad brush information paints a false picture: "In order to ease the implementation of new iterators, the Boost.Iterator library provides the iterator_facade class template, which implements many useful defaults and compile-time checks designed to help the author iterator ensure that his iterator is correct. It is common to define a new iterator which behaves like another iterator, but which modifies some aspect of its behavior. For that purpose, the library supplies the iterator_adaptor class template, which is specially designed to take advantage of as much of the underlying iterator's behavior as possible." By reading that, I was led to believe that I should use iterator_facade to create new iterators, and iterator_adaptor to modify existing iterators. Even the name "iterator_adaptor" provides no clue that it can also be used to create an iterator. If you approach the Introduction in iterator_adaptor.html with those preconceptions, it's easy to miss the implication that the base type need not be an iterator. Why not spell it out? In my opinion, for what it's worth, the documentation seems to be aimed at the developers of the library (so you're all singing from the same hymn sheet), rather than potential users. Clearly, both audiences need to be catered for - unless it was just an academic excercise. Of course, if you're already writing the text book for us users, then I completely understand the advantages of impenetrable free documentation ;-) Keith MacDonald
"Keith MacDonald" <boost@mailclan.net> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7k021gic.fsf@boost-consulting.com...
I realize the measure of docs is in their effectiveness, but do you really think there's anything wrong with painting with a broad brush on the main page and then providing detailed revision in specific docs? --
Only if the broad brush information paints a false picture:
"In order to ease the implementation of new iterators, the Boost.Iterator library provides the iterator_facade class template, which implements many useful defaults and compile-time checks designed to help the author iterator ensure that his iterator is correct. It is common to define a new iterator which behaves like another iterator, but which modifies some aspect of its behavior. For that purpose, the library supplies the iterator_adaptor class template, which is specially designed to take advantage of as much of the underlying iterator's behavior as possible."
By reading that, I was led to believe that I should use iterator_facade to create new iterators, and iterator_adaptor to modify existing iterators.
That's correct. Your Node* _is_ an existing iterator, as are all pointers.
Even the name "iterator_adaptor" provides no clue that it can also be used to create an iterator.
It's actually very rare that there's a non-iterator which provides enough of the useful iterator operations to be used with iterator adaptor (e.g. int, used with counting_iterator). I don't think there's anything wrong with making those details less apparent.
If you approach the Introduction in iterator_adaptor.html with those preconceptions, it's easy to miss the implication that the base type need not be an iterator. Why not spell it out?
If you spell everything out in the introduction, you need to write a new introduction.
In my opinion, for what it's worth, the documentation seems to be aimed at the developers of the library (so you're all singing from the same hymn sheet), rather than potential users.
How many times do I have to repeat that We're working on the docs. That document is the standards proposal, but the Boost (user-level) docs aren't complete yet. ??
Clearly, both audiences need to be catered for - unless it was just an academic excercise. Of course, if you're already writing the text book for us users, then I completely understand the advantages of impenetrable free documentation ;-)
I'm providing free software *and* free documentation as time allows; I really don't need to have my motivations insulted that way. A smiley doesn't make it funny. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Keith MacDonald" <boost@mailclan.net> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7k021gic.fsf@boost-consulting.com...
I realize the measure of docs is in their effectiveness, but do you really think there's anything wrong with painting with a broad brush on the main page and then providing detailed revision in specific docs? --
Only if the broad brush information paints a false picture:
"In order to ease the implementation of new iterators, the Boost.Iterator library provides the iterator_facade class template, which implements many useful defaults and compile-time checks designed to help the author iterator ensure that his iterator is correct. It is common to define a new iterator which behaves like another iterator, but which modifies some aspect of its behavior. For that purpose, the library supplies the iterator_adaptor class template, which is specially designed to take advantage of as much of
We're clearly on different wavelengths here. I've often found that if someone asks an apparently dumb question about my software, or its documentation, then it's better to improve the area in question, rather than tell the person he's not using or reading it correctly. That way, I've still got a happy customer and one less support issue to have to keep responding to. I was only trying to be helpful. Keith MacDonald "David Abrahams" <dave@boost-consulting.com> wrote in message news:u7k017ud5.fsf@boost-consulting.com... the
underlying iterator's behavior as possible."
By reading that, I was led to believe that I should use iterator_facade to create new iterators, and iterator_adaptor to modify existing iterators.
That's correct. Your Node* _is_ an existing iterator, as are all pointers.
Even the name "iterator_adaptor" provides no clue that it can also be used to create an iterator.
It's actually very rare that there's a non-iterator which provides enough of the useful iterator operations to be used with iterator adaptor (e.g. int, used with counting_iterator). I don't think there's anything wrong with making those details less apparent.
If you approach the Introduction in iterator_adaptor.html with those preconceptions, it's easy to miss the implication that the base type need not be an iterator. Why not spell it out?
If you spell everything out in the introduction, you need to write a new introduction.
In my opinion, for what it's worth, the documentation seems to be aimed at the developers of the library (so you're all singing from the same hymn sheet), rather than potential users.
How many times do I have to repeat that
We're working on the docs. That document is the standards proposal, but the Boost (user-level) docs aren't complete yet.
??
Clearly, both audiences need to be catered for - unless it was just an academic excercise. Of course, if you're already writing the text book for us users, then I completely understand the advantages of impenetrable free documentation ;-)
I'm providing free software *and* free documentation as time allows; I really don't need to have my motivations insulted that way. A smiley doesn't make it funny.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
"Keith MacDonald" <boost@mailclan.net> writes:
We're clearly on different wavelengths here. I've often found that if someone asks an apparently dumb question about my software, or its documentation, then it's better to improve the area in question, rather than tell the person he's not using or reading it correctly.
I'm 100% in agreement with that. You *weren't* reading it correctly, but it's clearly the fault of the documentation. The problem I'm having is seeing how to keep users from feeling misled by the statement that apparently misled you. Even if iterator_adaptor can be used to adapt non-iterators, that *is* a corner case. We'll be telling people to use iterator_facade when they're not starting with something very much like the iterator they want to end up with. That's just good advice. Should we say, "think hard about it and remember that pointers are iterators too?" I don't think so. I think it'd be better to just show your linked list example implemented with both iterator_facade and iterator adaptor in the detailed user-level examples that we'll provide. And we can't do that on the front page.
I was only trying to be helpful.
I'm sorry, I realize that part of your post was trying to be helpful, but I have a hard time seeing how your veiled accusation that we're keeping the workings of the library secret so that we can sell books is anything other than a cheap shot.
In my opinion, for what it's worth, the documentation seems to be aimed at the developers of the library (so you're all singing from the same hymn sheet), rather than potential users.
How many times do I have to repeat that
We're working on the docs. That document is the standards proposal, but the Boost (user-level) docs aren't complete yet.
??
I'm sorry that I lost my patience with you saying that user-level docs are needed, but c'mon, the library isn't released yet, and I had already told you we were still working on the docs (twice!) in this very thread. I think it's fair to let me know that the docs could be improved, but before the library has even entered a Boost release this amounts to harping on it.
Clearly, both audiences need to be catered for - unless it was just an academic excercise. Of course, if you're already writing the text book for us users, then I completely understand the advantages of impenetrable free documentation ;-)
I'm providing free software *and* free documentation as time allows; I really don't need to have my motivations insulted that way. A smiley doesn't make it funny.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
-- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uu13545id.fsf@boost-consulting.com...
The problem I'm having is seeing how to keep users from feeling misled by the statement that apparently misled you. Even if iterator_adaptor can be used to adapt non-iterators, that *is* a corner case. We'll be telling people to use iterator_facade when they're not starting with something very much like the iterator they want to end up with.
Well, if we go back to my question that started this thread, I asked: "I'm stuck trying to use iterator_adaptor from the CVS head. I simply want to derive a non-const iterator from a const one derived from iterator_facade, as shown in the code below." And you replied: "Answer: don't do that. Making iterators by derivation from other iterators is almost always an error (and in your case also: for example the return type of operator++ is wrong on the derived iterator). Make a new constant iterator type with iterator_facade. If you do it right, it will interoperate properly with your mutable iterator. <snip> Looks like a job for iterator_adaptor." I had problems compiling your suggested solution, so, I replied: "My working solution is now to use iterator_facade to declare instances of const_iterator and iterator, which are independent of each other, except that a const_iterator can be constructed from an iterator." And you responded: "Is that what your posting was doing? And you think that's simpler than what I did above?" I'm afraid that I did not deduce from that that this was a corner case. If your introduction to iterators is from using them with standard library containers, it's natural to want to do the same things with your own containers, to lever the power of the standard algorithms. If the first time you try, an expert says "don't do that", there is plenty of scope for the misunderstanding that followed.
I think it's fair to let me know that the docs could be improved, but before the library has even entered a Boost release this amounts to harping on it
I was commenting on the documentation that I have before me, and assumed that that was what you were working on. Therefore, I assumed that you would be open to suggestions as to how to improve it, _before_ it is released. Given the above, I would now like to see a separate section on how to use the Boost.Iterator library to implement bidirectional and random access iterators (both const and non-const) for simple containers. That may well satisfy the requirements of more than half the potential users of this library - which should cut down on the number of people asking "dumb" questions, like me.
I'm sorry, I realize that part of your post was trying to be helpful, but I have a hard time seeing how your veiled accusation that we're keeping the workings of the library secret so that we can sell books is anything other than a cheap shot.
It was meant as a joke - hence the use of the smiley. Is there a better convention for indicating jokes in email? Keith MacDonald
"Keith MacDonald" <boost@mailclan.net> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uu13545id.fsf@boost-consulting.com...
The problem I'm having is seeing how to keep users from feeling misled by the statement that apparently misled you. Even if iterator_adaptor can be used to adapt non-iterators, that *is* a corner case. We'll be telling people to use iterator_facade when they're not starting with something very much like the iterator they want to end up with.
Well, if we go back to my question that started this thread, I asked:
"I'm stuck trying to use iterator_adaptor from the CVS head. I simply want to derive a non-const iterator from a const one derived from iterator_facade, as shown in the code below."
And you replied:
"Answer: don't do that. Making iterators by derivation from other iterators is almost always an error (and in your case also: for example the return type of operator++ is wrong on the derived iterator). Make a new constant iterator type with iterator_facade. If you do it right, it will interoperate properly with your mutable iterator. <snip> Looks like a job for iterator_adaptor."
I had problems compiling your suggested solution, so, I replied:
"My working solution is now to use iterator_facade to declare instances of const_iterator and iterator, which are independent of each other, except that a const_iterator can be constructed from an iterator."
You also wrote: "I may have misunderstood the purpose of boost::iterator: I was expecting it to make it easy to add standard conforming iterators to any container, but the complexity of the proposed solution, (using iterator_adaptor, which I can't get to compile), is making me doubt that." Which I took to mean that you thought my solution was too complex, and far more complex than what you started with.
And you responded:
"Is that what your posting was doing? And you think that's simpler than what I did above?"
I'm afraid that I did not deduce from that that this was a corner case.
It's not a corner case (you *are* adapting an iterator), and my response wasn't intended to suggest it was. All I was suggesting was that your approach of using derivation to produce an iterator from a const_iterator was much more complicated than what I posted. Admittedly, my code was untested (and so labelled), but with a little investment in reading the specification, I'm sure you could've made the minor fixes I supplied.
If your introduction to iterators is from using them with standard library containers, it's natural to want to do the same things with your own containers, to lever the power of the standard algorithms. If the first time you try, an expert says "don't do that", there is plenty of scope for the misunderstanding that followed.
I'm sorry, I was saying "don't do that" about defining new iterators by deriving them from other iterators. Was that unclear? I am very confused at this point, since I don't see why it has any relationship to the misunderstanding followed.
I think it's fair to let me know that the docs could be improved, but before the library has even entered a Boost release this amounts to harping on it
I was commenting on the documentation that I have before me, and assumed that that was what you were working on. Therefore, I assumed that you would be open to suggestions as to how to improve it, _before_ it is released.
Yes, thanks. We already understand what needs to be done, basically, but I appreciate you taking the time to let us know. We are under a lot of pressure with a boost release coming up and many issues surrounding these proposals in the standards committee. That, combined with fending off hostility from one particular committee member is probably making me touchier than neccessary.
Given the above, I would now like to see a separate section on how to use the Boost.Iterator library to implement bidirectional and random access iterators (both const and non-const) for simple containers. That may well satisfy the requirements of more than half the potential users of this library - which should cut down on the number of people asking "dumb" questions, like me.
Your questions weren't dumb.
I'm sorry, I realize that part of your post was trying to be helpful, but I have a hard time seeing how your veiled accusation that we're keeping the workings of the library secret so that we can sell books is anything other than a cheap shot.
It was meant as a joke - hence the use of the smiley. Is there a better convention for indicating jokes in email?
Not that I know of. Calling it a joke doesn't make it less offensive though. Suppose I suggested that you were just demanding better documentation so that you could understand the library well enough to write an article claiming you came up with all the ideas and then we stole them from you? ;-) See what I mean? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ad4xqekh.fsf@boost-consulting.com...
We are under a lot of pressure with a boost release coming up and many issues surrounding these proposals in the standards committee.
I'd better leave you in peace to get on with that then.
Calling it a joke doesn't make it less offensive
A joke that you have to explain rapidly becomes very tiresome. However, it was not irony-free. Please don't take offense. Thanks again for your assistance with my problem. Keith MacDonald
"Keith MacDonald" <boost@mailclan.net> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ad4xqekh.fsf@boost-consulting.com...
We are under a lot of pressure with a boost release coming up and many issues surrounding these proposals in the standards committee.
I'd better leave you in peace to get on with that then.
Calling it a joke doesn't make it less offensive
A joke that you have to explain rapidly becomes very tiresome.
Really? I always thought that jokes get funnier when explained. A *lot* funnier. irony-free-ly y'rs, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Keith MacDonald" <boost@mailclan.net> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ad4xqekh.fsf@boost-consulting.com...
We are under a lot of pressure with a boost release coming up and many issues surrounding these proposals in the standards committee.
I'd better leave you in peace to get on with that then.
You might look at the CVS or http://www.boost-consulting.com/libs/iterator/doc/index.html if you're interested in the progress we've made so far. We'd really appreciate any feedback you have for us (really!). Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Keith MacDonald" <boost@mailclan.net> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ad4xqekh.fsf@boost-consulting.com...
We are under a lot of pressure with a boost release coming up and many issues surrounding these proposals in the standards committee.
I'd better leave you in peace to get on with that then.
You might look at the CVS or http://www.boost-consulting.com/libs/iterator/doc/index.html if you're
Arf, sorry: http://www.boost-consulting.com/boost/libs/iterator/doc/index.html
interested in the progress we've made so far. We'd really appreciate any feedback you have for us (really!).
-- Dave Abrahams Boost Consulting www.boost-consulting.com
I know you're in a hurry, so I'll just comment on the documentation as I go, rather than saving everything up until the end. 1. This is probably in the generator you're using for the HTML files: the cursor behaves like it's over an active link, when it's over a heading. This is due to lines like the following: <h1><a class="toc-backref" href="#id6" name="new-style-iterators">New-Style Iterators</a></h1> It would be less confusing if the anchor tag was moved, like this: <a class="toc-backref" href="#id6" name="new-style-iterators"></a> <h1>New-Style Iterators</h1> 2. I like the changes to the paragraph "Iterator Facade and Adaptor" in index.html. Using "type" instead of "iterator" was simple, but effective. 3. Have you considered adding a "road map" to index.html? Possibly like the "Other Documents" links at the head of boost/libs/filesystem/doc/index.htm, or like the "How to read this" section in the Boost.Signals documentation. It would help the new reader judge how much time to allocate to reading the documentation, and provide a handy starting point, if you get lost. 4. I got the updated documentation using CVS update, which broke my copy of iterator_facade.hpp, because the CVS head copy contains this code: template <class Iterator, class Value, class Reference> struct operator_brackets_result { typedef typename mpl::if_< <<<<<<< iterator_facade.hpp iterator_writability_disabled<Value,Reference> , Value ======= use_operator_brackets_proxy<Value,Reference> , Value
> 1.15 , operator_brackets_proxy<Iterator> >::type type; };
Regards, Keith MacDonald "David Abrahams" <dave@boost-consulting.com> wrote in message news:uad4tmb0b.fsf@boost-consulting.com...
You might look at the CVS or http://www.boost-consulting.com/libs/iterator/doc/index.html if you're interested in the progress we've made so far. We'd really appreciate any feedback you have for us (really!).
Thanks,
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Sorry, forget point 4, about iterator_facade.hpp. I reinstated the wrong copy before running CVS update. It's my problem. Keith MacDonald "Keith MacDonald" <boost@mailclan.net> wrote in message news:btun9k$f58$1@sea.gmane.org...
4. I got the updated documentation using CVS update, which broke my copy
of
iterator_facade.hpp, because the CVS head copy contains this code:
template <class Iterator, class Value, class Reference> struct operator_brackets_result { typedef typename mpl::if_< <<<<<<< iterator_facade.hpp iterator_writability_disabled<Value,Reference> , Value ======= use_operator_brackets_proxy<Value,Reference> , Value
>> 1.15 , operator_brackets_proxy<Iterator> >::type type; };
Regards, Keith MacDonald
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uad4tmb0b.fsf@boost-consulting.com...
You might look at the CVS or http://www.boost-consulting.com/libs/iterator/doc/index.html if you're interested in the progress we've made so far. We'd really appreciate any feedback you have for us (really!).
Thanks,
-- Dave Abrahams Boost Consulting www.boost-consulting.com
"Keith MacDonald" <boost@mailclan.net> writes:
I know you're in a hurry, so I'll just comment on the documentation as I go, rather than saving everything up until the end.
1. This is probably in the generator you're using for the HTML files: the cursor behaves like it's over an active link, when it's over a heading.
It's intentional. It *is* over an active link. You can bounce back and forth between the TOC and the various sections. I happen to like that behavior, but it could be turned off. I don't see a reason to, though.
This is due to lines like the following:
<h1><a class="toc-backref" href="#id6" name="new-style-iterators">New-Style Iterators</a></h1>
It would be less confusing if the anchor tag was moved, like this:
<a class="toc-backref" href="#id6" name="new-style-iterators"></a> <h1>New-Style Iterators</h1>
Why would that be less confusing?
2. I like the changes to the paragraph "Iterator Facade and Adaptor" in index.html. Using "type" instead of "iterator" was simple, but effective.
3. Have you considered adding a "road map" to index.html?
I hadn't.
Possibly like the "Other Documents" links at the head of boost/libs/filesystem/doc/index.htm, or like the "How to read this" section in the Boost.Signals documentation. It would help the new reader judge how much time to allocate to reading the documentation, and provide a handy starting point, if you get lost.
It's a great idea.
4. I got the updated documentation using CVS update, which broke my copy of iterator_facade.hpp, because the CVS head copy contains this code:
template <class Iterator, class Value, class Reference> struct operator_brackets_result { typedef typename mpl::if_< <<<<<<< iterator_facade.hpp iterator_writability_disabled<Value,Reference> , Value ======= use_operator_brackets_proxy<Value,Reference> , Value
>> 1.15 , operator_brackets_proxy<Iterator> >::type type; };
No it doesn't; that's just CVS respecting the local changes you made to your copy of iterator_facade.hpp. You can update with -C to throw those away. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Keith MacDonald" <boost@mailclan.net> writes:
Possibly like the "Other Documents" links at the head of boost/libs/filesystem/doc/index.htm, or like the "How to read this" section in the Boost.Signals documentation. It would help the new reader judge how much time to allocate to reading the documentation, and provide a handy starting point, if you get lost.
It's a great idea.
Would you care to propose something? We're running short of time and anything you could do to help improve the docs would really be appreciated. -- Dave Abrahams Boost Consulting www.boost-consulting.com
[Sorry that this is uselessly late] On 1/12/04 5:57 PM, "David Abrahams" <dave@boost-consulting.com> wrote:
"Keith MacDonald" <boost@mailclan.net> writes: [SNIP]
This is due to lines like the following:
<h1><a class="toc-backref" href="#id6" name="new-style-iterators">New-Style Iterators</a></h1>
It would be less confusing if the anchor tag was moved, like this:
<a class="toc-backref" href="#id6" name="new-style-iterators"></a> <h1>New-Style Iterators</h1>
Why would that be less confusing? [TRUNCATE]
In fact, this would be worse. The anchor takes up zero area. This is sort-of acceptable for a link destination, but it's definitely bad for a link source, since it's now (practically) un-clickable! The HTML standard allows anchors to be sources and destinations simultaneously; take advantage of that if needed. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
participants (4)
-
Daniel Wallin -
Daryle Walker -
David Abrahams -
Keith MacDonald