Hi Wouldn't it be convenient if iterator_adaptor provided a protected "self typedef" for use by client code? In particular I'm thinking of the constructor case that basically always is feeding an iterator to the iterator_adaptor baseclass, thus needing its explicit type. (In most examples and tests this typedef is manually created as a 'super_t' for example). Having a predefined type would reduce the amount of boilerplate code and the risk of getting out-of-sync with the declaration. I suggest a name something like 'iterator_adaptor_t' instead of 'super_t' to lessen name-clash possibility. I'm a bit confused why I haven't seen this discussed previously though. Hope I'm not missing something (tm).. ;-) Regards // Fredrik Blomqvist
Fredrik Blomqvist wrote:
Wouldn't it be convenient if iterator_adaptor provided a protected "self typedef" for use by client code? In particular I'm thinking of the constructor case that basically always is feeding an iterator to the iterator_adaptor baseclass, thus needing its explicit type. (In most examples and tests this typedef is manually created as a 'super_t' for example).
Having a predefined type would reduce the amount of boilerplate code and the risk of getting out-of-sync with the declaration. I suggest a name something like 'iterator_adaptor_t' instead of 'super_t' to lessen name-clash possibility.
I'm not sure this is going to work: template<class T> class yours : public iterator_facade<T, ...> { public: yours(.....) : super_t(.......) { } }; When compiler parses the above, name lookup does not use the scope of iterator_facade, so no matter what's typedefed there, 'super_t' won't be found. - Volodya
Vladimir Prus wrote:
Fredrik Blomqvist wrote:
Wouldn't it be convenient if iterator_adaptor provided a protected "self typedef" for use by client code? In particular I'm thinking of the constructor case that basically always is feeding an iterator to the iterator_adaptor baseclass, thus needing its explicit type. (In most examples and tests this typedef is manually created as a 'super_t' for example).
Having a predefined type would reduce the amount of boilerplate code and the risk of getting out-of-sync with the declaration. I suggest a name something like 'iterator_adaptor_t' instead of 'super_t' to lessen name-clash possibility.
I'm not sure this is going to work:
template<class T> class yours : public iterator_facade<T, ...> { public: yours(.....) : super_t(.......) { } };
When compiler parses the above, name lookup does not use the scope of iterator_facade, so no matter what's typedefed there, 'super_t' won't be found.
Initially I had similar thoughts but since it compiled (and worked ok) in VC7.1 I figured it might be legal and would be a neat improvement. Reproducing the situation: ------------------ template <class T, class Y> class base { protected: typedef base<T, Y> super_t; public: explicit base(T const& v) : m_v(v) {} private: T m_v; }; template <class T> class derived : public base<T, T*> { public: derived(T const& v) : super_t(v) {} }; derived<int> test(123); ---------------- I tried out the code above in Comeau online (strict mode) and -- it failed :( msg: "super_t" is not a nonstatic data member or base class of class "derived<T>" Confirming your theory. In VC7.1 and Comeau non-strict (relaxed) mode it compiled fine though.. Oh, well. Regards // Fredrik
"Fredrik Blomqvist" <fredrik_blomqvist@home.se> writes:
Vladimir Prus wrote:
Fredrik Blomqvist wrote:
Wouldn't it be convenient if iterator_adaptor provided a protected "self typedef" for use by client code? In particular I'm thinking of the constructor case that basically always is feeding an iterator to the iterator_adaptor baseclass, thus needing its explicit type. (In most examples and tests this typedef is manually created as a 'super_t' for example).
Having a predefined type would reduce the amount of boilerplate code and the risk of getting out-of-sync with the declaration. I suggest a name something like 'iterator_adaptor_t' instead of 'super_t' to lessen name-clash possibility.
I'm not sure this is going to work:
template<class T> class yours : public iterator_facade<T, ...> { public: yours(.....) : super_t(.......) { } };
When compiler parses the above, name lookup does not use the scope of iterator_facade, so no matter what's typedefed there, 'super_t' won't be found.
Initially I had similar thoughts but since it compiled (and worked ok) in VC7.1 I figured it might be legal and would be a neat improvement.
It ain't. But what you _can_ do is: derived(T const& v) : derived::super_t(v) {} I'm afraid that not every compiler supports that either, but I'm not certain. It's an interesting thought. I'll put it in the queue of iterator library issues I'm working on. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote: [snip]
But what you _can_ do is:
derived(T const& v) : derived::super_t(v) {}
I'm afraid that not every compiler supports that either, but I'm not certain. It's an interesting thought. I'll put it in the queue of iterator library issues I'm working on.
Sounds good! FWIW the syntax above compiles ok in atleast VC7.1 and Comeau online (all versions). Thanks for looking into this. // Fredrik Blomqvist
"Fredrik Blomqvist" <fredrik_blomqvist@home.se> writes:
David Abrahams wrote: [snip]
But what you _can_ do is:
derived(T const& v) : derived::super_t(v) {}
I'm afraid that not every compiler supports that either, but I'm not certain. It's an interesting thought. I'll put it in the queue of iterator library issues I'm working on.
Sounds good! FWIW the syntax above compiles ok in atleast VC7.1 and Comeau online (all versions).
But not Borland or CWPro8 (pro9 is fine). I'm soliciting suggestions for the name of the member. All names with suffixes like "_t" will be rejected, and be aware that base is already taken for other purposes. Currently my thoughts are super // super crtp // ugly Dave -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
I'm soliciting suggestions for the name of the member. All names with suffixes like "_t" will be rejected, and be aware that base is already taken for other purposes. Currently my thoughts are
super // super crtp // ugly
parent? parent_class? base_class? super_class? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
David Abrahams wrote: [snip]
I'm soliciting suggestions for the name of the member. All names with suffixes like "_t" will be rejected, and be aware that base is already taken for other purposes. Currently my thoughts are
super // super crtp // ugly
Why not something related to "iterator" and/or "adaptor"? iterator_adaptor_base? adaptor_base? // Fredrik
"Fredrik Blomqvist" <fredrik_blomqvist@home.se> writes:
David Abrahams wrote: [snip]
I'm soliciting suggestions for the name of the member. All names with suffixes like "_t" will be rejected, and be aware that base is already taken for other purposes. Currently my thoughts are
super // super crtp // ugly
Why not something related to "iterator" and/or "adaptor"? iterator_adaptor_base? adaptor_base?
and iterator_facade_base or facade_base? Hmm, I guess in case of multiple inheritance that approach is more useful. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Fredrik Blomqvist" <fredrik_blomqvist@home.se> writes:
David Abrahams wrote: [snip]
I'm soliciting suggestions for the name of the member. All names with suffixes like "_t" will be rejected, and be aware that base is already taken for other purposes. Currently my thoughts are
super // super crtp // ugly
Why not something related to "iterator" and/or "adaptor"? iterator_adaptor_base? adaptor_base?
and iterator_facade_base or facade_base?
Hmm, I guess in case of multiple inheritance that approach is more useful.
OK, now done. The typedefs are iterator_facade_ and iterator_adaptor_. Cheers, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (4)
-
David Abrahams -
Fredrik Blomqvist -
Rob Stewart -
Vladimir Prus