Minimizing Dependencies within Generic Classes for Faster and Smaller Programs
Hi, I have found this paper "Minimizing Dependencies within Generic Classes for Faster and Smaller Programs" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2911.pdf quite iteresting. The gain in performances and reduced space could be considerable. I was wondering if Boost should not take this as a guideline and whether the Boost authors would check his libraries to see if this technique could improve its performances, in particular for all the container and the the forthcomming Boost.Container libraries. I would be interested in knowing if this has been adopted for C==0x containers. Good reading, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/
On 10/11/2010 17:56, vicente.botet wrote:
Hi,
I have found this paper "Minimizing Dependencies within Generic Classes for Faster and Smaller Programs" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2911.pdf quite iteresting. The gain in performances and reduced space could be considerable.
I was wondering if Boost should not take this as a guideline and whether the Boost authors would check his libraries to see if this technique could improve its performances, in particular for all the container and the the forthcomming Boost.Container libraries.
I plan to implement this technique for Boost.Container if the library is accepted, but I need a review manager. Willing to help? ;-) Best, Ion
----- Original Message ----- From: "Ion Gaztañaga" <igaztanaga@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, November 11, 2010 10:23 PM Subject: Re: [boost] Minimizing Dependencies within Generic Classes for Faster and Smaller Programs
On 10/11/2010 17:56, vicente.botet wrote:
Hi,
I have found this paper "Minimizing Dependencies within Generic Classes for Faster and Smaller Programs" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2911.pdf quite iteresting. The gain in performances and reduced space could be considerable.
I was wondering if Boost should not take this as a guideline and whether the Boost authors would check his libraries to see if this technique could improve its performances, in particular for all the container and the the forthcomming Boost.Container libraries.
I plan to implement this technique for Boost.Container if the library is accepted, but I need a review manager. Willing to help? ;-)
Of course. It will be a pleasure to help you in this refactoring. Let me know what I can do? Best, Vicente
I plan to implement this technique for Boost.Container if the library is accepted, but I need a review manager. Willing to help? ;-)
Of course. It will be a pleasure to help you in this refactoring. Let me know what I can do?
I need a review manager ;-) Best, Ion
2010/11/12 Ion Gaztañaga <igaztanaga@gmail.com>:
On 10/11/2010 17:56, vicente.botet wrote:
I was wondering if Boost should not take this as a guideline and whether the Boost authors would check his libraries to see if this technique could improve its performances, in particular for all the container and the the forthcomming Boost.Container libraries.
Interesting paper, thanks for sharing Vicente. I already use this technique in cpp-netlib, I just didn't know there was a general term for it. :D
I plan to implement this technique for Boost.Container if the library is accepted, but I need a review manager. Willing to help? ;-)
Cool. I'm lining up to be a reviewer, but not as a review manager. I'll definitely look forward to Boost.Container. :D -- Dean Michael Berris deanberris.com
----- Original Message ----- From: "Dean Michael Berris" <mikhailberis@gmail.com> To: <boost@lists.boost.org> Sent: Thursday, November 11, 2010 11:15 PM Subject: Re: [boost] Minimizing Dependencies within Generic Classes for Faster and Smaller Programs
2010/11/12 Ion Gaztañaga <igaztanaga@gmail.com>:
On 10/11/2010 17:56, vicente.botet wrote:
I was wondering if Boost should not take this as a guideline and whether the Boost authors would check his libraries to see if this technique could improve its performances, in particular for all the container and the the forthcomming Boost.Container libraries.
Interesting paper, thanks for sharing Vicente. I already use this technique in cpp-netlib, I just didn't know there was a general term for it. :D
I use it also though not systematicaly, but I didn't know that there were cases were this technique could improve the performances so significantly. Vicente
2010/11/11 Ion Gaztañaga <igaztanaga@gmail.com>:
[snip]
I plan to implement this technique for Boost.Container if the library is accepted,
It seems that for C++0X, you must make the red-black-tree dependent on Allocator, since you must use Allocator::pointer everywhere. Or am I missing something? The technique seems indeed very good. Though after reading I felt like: "How didn't I think of it before?". It also feels right to eliminate unused dependencies for parametrization.
but I need a review manager. Willing to help? ;-)
Best,
Ion
Regards, -- Felipe Magno de Almeida
----- Original Message ----- From: "Felipe Magno de Almeida" <felipe.m.almeida@gmail.com> To: <boost@lists.boost.org> Sent: Friday, November 12, 2010 10:44 AM Subject: Re: [boost] Minimizing Dependencies within Generic Classes for Faster and Smaller Programs 2010/11/11 Ion Gaztañaga <igaztanaga@gmail.com>:
[snip]
I plan to implement this technique for Boost.Container if the library is accepted,
It seems that for C++0X, you must make the red-black-tree dependent on Allocator, since you must use Allocator::pointer everywhere. Or am I missing something? _______________________________________________ Hi, The iterator can depend on the Allocator::pointer but this doesn't forcerly means that it depends on the Allocator. If Allocator::pointer is a typedef to a type idependent of Allocator the independency is ensured. In addition we could make iterator depend on Allocator::void_pointer and use pointer_traits<>::rebind. Am I missing something? Best, Vicente
On 12 November 2010 12:42, vicente.botet <vicente.botet@wanadoo.fr> wrote:
The iterator can depend on the Allocator::pointer but this doesn't forcerly means that it depends on the Allocator. If Allocator::pointer is a typedef to a type idependent of Allocator the independency is ensured.
In addition we could make iterator depend on Allocator::void_pointer and use pointer_traits<>::rebind.
Am I missing something?
If the node contains a pointer to node, then to work out the type of the pointer, you need to know the type of the node. But you can't know that until you know the type of the pointer. For example: template <typename NodePtr> struct node { NodePtr next_; }; How do you write the node typedef? What's the ??? parameter in: typedef typename node< typename Allocator::template rebind<???>::other::pointer > node_type; But if you use allocator: template <typename Allocator> struct node { typedef typename Allocator::template rebind<node>::other::pointer node_ptr; node_ptr next_; }; typedef node<Allocator> node_type; IIRC C++0x is going to introduce a trait for this purpose, so we'll be able to write something like: template <typename VoidPtr> struct node { typedef typename convert_pointer<VoidPtr, node> node_ptr; node_ptr next_; }; But we can't do that until the trait is available for current custom pointer types. Daniel
----- Original Message ----- From: "Daniel James" <dnljms@gmail.com> To: <boost@lists.boost.org> Sent: Friday, November 12, 2010 5:36 PM Subject: Re: [boost] Minimizing Dependencies within Generic Classes for Faster and Smaller Programs On 12 November 2010 12:42, vicente.botet <vicente.botet@wanadoo.fr> wrote:
The iterator can depend on the Allocator::pointer but this doesn't forcerly means that it depends on the Allocator. If Allocator::pointer is a typedef to a type idependent of Allocator the independency is ensured.
In addition we could make iterator depend on Allocator::void_pointer and use pointer_traits<>::rebind.
Am I missing something?
If the node contains a pointer to node, then to work out the type of the pointer, you need to know the type of the node. But you can't know that until you know the type of the pointer. For example: template <typename NodePtr> struct node { NodePtr next_; }; How do you write the node typedef? What's the ??? parameter in: typedef typename node< typename Allocator::template rebind<???>::other::pointer > node_type; _______________________________ Vicente> has the following sens? template <class T, class VoidPtr> struct c_node { typedef typename pointer_traits<VoidPtr>::template rebind<c_node<T, VoidPtr> >::other node_pointer; node_pointer next_; T value_; c_node() : next_(static_cast<node_pointer>(this)) {} }; ____________________________________________________________ But if you use allocator: template <typename Allocator> struct node { typedef typename Allocator::template rebind<node>::other::pointer node_ptr; node_ptr next_; }; typedef node<Allocator> node_type; IIRC C++0x is going to introduce a trait for this purpose, so we'll be able to write something like: template <typename VoidPtr> struct node { typedef typename convert_pointer<VoidPtr, node> node_ptr; node_ptr next_; }; But we can't do that until the trait is available for current custom pointer types. Daniel _______________________________________________ Vicente> You are right, we need this trait. BTW, are you referring to pointer_traits when you use convert_pointer, isn't it? Yes. One of the first things to do should be to define this trait class :( With pointer_traits, the container iterator could look like: template <class T, class VoidPtr> class c_iterator { typedef typename pointer_traits<VoidPtr>::template rebind<c_node<T, VoidPtr> >::other node_pointer; node_pointer ptr_; explicit c_iterator(node_pointer p) : ptr_(p) {} ... }; and the container implementation could look like template <class T, class A> class c_imp { potected: typedef T value_type; typedef A allocator_type; typedef allocator_traits<allocator_type> alloc_traits; typedef typename alloc_traits::void_pointer void_pointer; typedef c_iterator<value_type, void_pointer> iterator; ... }; In this way the c_iterator class doesn't depend on the Allocator. It depends only on the stored type T and the Allocator void_pointer type. Best, Vicente
On 12 November 2010 18:33, vicente.botet <vicente.botet@wanadoo.fr> wrote:
IIRC C++0x is going to introduce a trait for this purpose, so we'll be able to write something like:
template <typename VoidPtr> struct node { typedef typename convert_pointer<VoidPtr, node> node_ptr; node_ptr next_; };
But we can't do that until the trait is available for current custom pointer types.
Vicente> You are right, we need this trait. BTW, are you referring to pointer_traits when you use convert_pointer, isn't it?
Probably, I was just writing up what I remembered from when I tried to implement this for Boost.Unordered a while back. Daniel
On 12/11/2010 17:36, Daniel James wrote:
On 12 November 2010 12:42, vicente.botet<vicente.botet@wanadoo.fr> wrote:
The iterator can depend on the Allocator::pointer but this doesn't forcerly means that it depends on the Allocator. If Allocator::pointer is a typedef to a type idependent of Allocator the independency is ensured.
In addition we could make iterator depend on Allocator::void_pointer and use pointer_traits<>::rebind.
Am I missing something?
If the node contains a pointer to node, then to work out the type of the pointer, you need to know the type of the node. But you can't know that until you know the type of the pointer. For example:
In boost we have pointer_to_other to obtain a pointer to a different type. This utility partly inspired new C++0x pointer utilities. Best, Ion
On 11/10/2010 11:56 AM, vicente.botet wrote:
Hi,
I have found this paper "Minimizing Dependencies within Generic Classes for Faster and Smaller Programs" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2911.pdf quite iteresting. The gain in performances and reduced space could be considerable.
I was wondering if Boost should not take this as a guideline and whether the Boost authors would check his libraries to see if this technique could improve its performances, in particular for all the container and the the forthcomming Boost.Container libraries.
I would be interested in knowing if this has been adopted for C==0x containers.
Good reading, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/ _______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
It looks like multi index container could greatly benefit from it. In fact, I think the example in the paper really represents an implementation of a multiindex container. Or is multi-index already employing this technique? Thanks, Andy.
----- Original Message ----- From: "Andy Venikov" <avenikov@gmail.com> To: <boost@lists.boost.org> Sent: Friday, November 12, 2010 7:21 PM Subject: Re: [boost] Minimizing Dependencies within Generic Classes for Faster and Smaller Programs It looks like multi index container could greatly benefit from it. In fact, I think the example in the paper really represents an implementation of a multiindex container. Or is multi-index already employing this technique? _______________________________________________ Hi, The example in the paper coudl be considered as a kind of dynamic polymorphic multi-index. Boost.MultiIndex uses static polymorphism. I don't know if MultiIndex uses this technique. Joaquin? Vicente
vicente.botet <vicente.botet <at> wanadoo.fr> writes:
----- Original Message ----- From: "Andy Venikov" <avenikov <at> gmail.com> To: <boost <at> lists.boost.org> Sent: Friday, November 12, 2010 7:21 PM Subject: Re: [boost] Minimizing Dependencies within Generic Classes for Faster
and Smaller Programs
It looks like multi index container could greatly benefit from it. In fact, I think the example in the paper really represents an implementation of a multiindex container.
Or is multi-index already employing this technique?
_______________________________________________ Hi, The example in the paper coudl be considered as a kind of dynamic polymorphic multi-index. Boost.MultiIndex uses static polymorphism. I don't know if MultiIndex uses this technique. Joaquin?
Hi Andy and Vicente, Boost.MultiIndex iterators are not SCARY (better said, they are not SCARY in the way it'd be really useful) for the following independent reasons: 1. When in safe mode (http://tinyurl.com/37cq7tp ), iterators need to access internal information of the index they are associated to, hence they are dependent on the index type. In fact, I think this is a general problem of the SCARY approach with safe- or checked- iterator modes provided by some STL implementations. 2. When not in safe mode, the iterator type is not pure-SCARY in that it depends not only on the value type, but also on the allocator type. Why so? Because this dependency allows for the creation of advanced (and useful) shared-memory containers by way of Boost.Interprocess allocators, see http://tinyurl.com/2vfpbpw . Again, I think this is a potential general problem (not specifically related to Boost.MultiIndex) of the SCARY approach. 3. With these caveats, Boost.MultiIndex iterators can be said to be SCARY as long as they belong to the same category of index (ordered, hashed, sequenced, random.access) in some situations, not in others. For instance, the following compiles and works: // example 1 typedef multi_index_container< int, indexed_by< ordered_unique<identity<int> > >
multi_t1;
typedef multi_index_container< int, indexed_by< ordered_non_unique<identity<int>,std::greater<int> > >
multi_t2;
multi_t1::nth_index<0>::type::iterator it1; multi_t2::nth_index<0>::type::iterator it2; it1=it2; // SCARY! but the following, which would be far more useful, does *not* work: // example 2 typedef multi_index_container< int, indexed_by< ordered_unique<identity<int> >, ordered_non_unique<identity<int>,std::greater<int> > >
multi_t;
multi_t::nth_index<0>::type::iterator it1; multi_t::nth_index<1>::type::iterator it2; it1=it2; To understand why example 2does not work, and cannot be made to work without some runtime penalty, consider the typical (somewhat idealized) node structure of a std::set: struct node { int color; node* parent,left,right; value_type value; }; Obviously, iterators for independent std::set types with the same value_type are pointing to the same kinf of stuff, so SCARY is in principle possible. Now, the node structure of a two-index multi_index_container like the one defined at example 2 looks like this: struct node { int color1; node* parent1,left1,right1; int color2; node* parent2,left2,right2; value_type value; }; iterators associated to the first index do use the first group of tree traversal parameters (color1, parent1, left1, right1) whereas iterators associated to the second index use the second group (color2, parent2, left2, right2). So, it1 and it2 types *need* to be different because they act differently, and this is why the line it1=it2; results in a compiler error. To make the SCARY assignment work, that is, to allow for it1 and it2 to be of the same type, such a "unified" operator would have to be provided with some runtime info as to whether to use the first or the second group of tree taversal parameters. This of course is not optimal in terms of speed or space. The example developed at N2911 comes close to what could be thought of as a dynamic multi_index_container. This beast has pros and cons with respect to the current static multi_index_container, which are more or less those of dynamic vs. static approaches: - dynamic allows for run-time specification and modification of the indices comprising the container, and, if well designed, for SCARY assignment. - dynamic has some unavoidable penalties in performance and space consumption. Some years ago I played a little with a toy prototype of a dynamic multi_index_container but never went too far since I didn't see much public interest in the idea (and, truth be said, writing this is no minor task). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
On Nov 13, 2:37 pm, Joaquin M Lopez Munoz <joaq...@tid.es> wrote:
Boost.MultiIndex iterators are not SCARY (better said, they are not SCARY in the way it'd be really useful) for the following independent reasons:
1. When in safe mode (http://tinyurl.com/37cq7tp), iterators need to access internal information of the index they are associated to, hence they are dependent on the index type. In fact, I think this is a general problem of the SCARY approach with safe- or checked- iterator modes provided by some STL implementations.
I think you're right, but I believe the original SCARY paper (see [1]) suggests a way to address this issue (or at least a similar issue) in the last paragraph of Section 3.2.
2. When not in safe mode, the iterator type is not pure-SCARY in that it depends not only on the value type, but also on the allocator type. Why so? Because this dependency allows for the creation of advanced (and useful) shared-memory containers by way of Boost.Interprocess allocators, see http://tinyurl.com/2vfpbpw. Again, I think this is a potential general problem (not specifically related to Boost.MultiIndex) of the SCARY approach.
I believe this very issue was addressed and solved by the committee. Specifically, the allocator proposal (which got accepted to c++0x) was revised to include the following paragraph (see p. 5 of [2]): "The key requirements for an allocator’s pointer type are that it has pointer-like syntax (i.e., it can be dereferenced using operator*), that it is implicitly convertible to the corresponding void_pointer and explicitly convertible from the corresponding void_pointer, and that there exists a specialization of the pointer_traits class template, which describes a number of key attributes of the pointer type. If an allocator does not define a pointer type, allocator_traits will provide default types for pointer, const_pointer, void_pointer, and const_void_pointer of value_type*, const value*, void*, and const void*, respectively. The above pointer requirements were carefully crafted to be harmonious with the intent of N2913 (SCARY Iterator Assignment and Initialization)." The SCARY proposal was synchronously revised to allow the iterator to depend upon the types X::allocator_type::const_void_pointer and X::allocator_type::void_pointer (where X is a container) thereby ridding programmers from the need to depend on the allocator type (see [3]). The mailing list thread in [4] includes the discussion of this issue by Stroustrup and friends, and, in particular, it includes Howard Hinnant's explanation regarding how/why the SCARY proposal prompted the revision of the allocator definition (I'm quoting the relevant text below). ---- refs: ---- [1] "Minimizing Dependencies within Generic Classes for Faster & Smaller Programs", http://www2.research.att.com/~bs/SCARY.pdf [2] "Allocators post Removal of C++ Concepts (Rev 1)", committee paper N2982 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf [3] "SCARY Iterator Assignment & Initialization (Rev 1)", committee paper N2980 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2980.pdf [4] "Ext pointer vs N2913", libstdc++ mailing list thread, http://gcc.gnu.org/ml/libstdc++/2009-10/msg00074.html ---- relevant text from [4]: ---- From: Howard Hinnant <howard.hinnant@gmail.com> To: undisclosed-recipients:; Errors-To: c++std-postmaster@accu.org Reply-To: c++std-lib@accu.org Sender: c++std=lib@accu.org To: C++ libraries mailing list Message c++std-lib-24867 [snip] Then I came upon a very simple piece of infrastructure (only two weeks ago) which allows SCARY and generalized pointers to mix without forcing node hierarchies or forcing casting: namespace std { template <class Ptr> struct pointer_traits { typedef Ptr pointer; typedef typename pointer::value_type value_type; template <class U> using rebind = typename pointer::template rebind<U>; }; template <class T> struct pointer_traits<T*> { typedef T* pointer; typedef T value_type; template <class U> using rebind = U*; }; } // std Now one can say: template <class T, class VoidPtr> struct __list_node { typedef pointer_traits<VoidPtr>::template rebind<__list_node> pointer; pointer prev_; pointer next_; T value_; }; I.e. you can get a generalized void* -> node* type transformation. Generalized pointers can easily hook into this infrastructure. I've prototyped it. Pablo has independently implemented it and is busy writing it up as a very minor revision to his pre-Santa Cruz N2946. Daniel is reviewing the heck out of it (as usual). I believe this is significant new information for the SCARY debate. [snip] With pointer_traits I think SCARY is quite practical. It provides the *essential* allocator-less transformation from T* to U*. With pointer_traits I can see SCARY as either encouraged or mandated (I'm not going to nail myself to either one of those two options). I encourage all to take another look in light of this new information. And I feel it is worth the time to discuss again in Santa Cruz. -Howard
Dan Tsafrir wrote:
On Nov 13, 2:37 pm, Joaquin M Lopez Munoz <joaq...@tid.es> wrote:
Boost.MultiIndex iterators are not SCARY (better said, they are not SCARY in the way it'd be really useful) for the following independent reasons:
1. When in safe mode (http://tinyurl.com/37cq7tp), iterators need to access internal information of the index they are associated to, hence they are dependent on the index type. In fact, I think this is a general problem of the SCARY approach with safe- or checked- iterator modes provided by some STL implementations.
I think you're right, but I believe the original SCARY paper (see [1]) suggests a way to address this issue (or at least a similar issue) in the last paragraph of Section 3.2.
Oh yes. Let me quote the paragraph: "But there is no need to make the iterator dependent on its std::set in order to perform these checks; this is just another example of an unwarranted dependency that delivers no real benefit. Indeed, instead of the std::set, the iterator can point to the root node of the balanced tree (which, as explained in Section 3.1, should not depend on the comparator and allocator); the begin and end of the tree are immediately accessible through this root."
2. When not in safe mode, the iterator type is not pure-SCARY in that it depends not only on the value type, but also on the allocator type. Why so? Because this dependency allows for the creation of advanced (and useful) shared-memory containers by way of Boost.Interprocess allocators, see http://tinyurl.com/2vfpbpw. Again, I think this is a potential general problem (not specifically related to Boost.MultiIndex) of the SCARY approach.
I believe this very issue was addressed and solved by the committee. Specifically, the allocator proposal (which got accepted to c++0x) was revised to include the following paragraph (see p. 5 of [2]):
"The key requirements for an allocator’s pointer type are that it has pointer-like syntax (i.e., it can be dereferenced using operator*), that it is implicitly convertible to the corresponding void_pointer and explicitly convertible from the corresponding void_pointer, and that there exists a specialization of the pointer_traits class template, which describes a number of key attributes of the pointer type. If an allocator does not define a pointer type, allocator_traits will provide default types for pointer, const_pointer, void_pointer, and const_void_pointer of value_type*, const value*, void*, and const void*, respectively. The above pointer requirements were carefully crafted to be harmonious with the intent of N2913 (SCARY Iterator Assignment and Initialization)."
The SCARY proposal was synchronously revised to allow the iterator to depend upon the types X::allocator_type::const_void_pointer and X::allocator_type::void_pointer (where X is a container) thereby ridding programmers from the need to depend on the allocator type (see [3]).
From what I read this should answer I question I posted in this thread. It seems that the C++0x proposal is taking in account this technique seriously. Does C++0x proposal requires SCARY implementations for containers?
The mailing list thread in [4] includes the discussion of this issue by Stroustrup and friends, and, in particular, it includes Howard Hinnant's explanation regarding how/why the SCARY proposal prompted the revision of the allocator definition (I'm quoting the relevant text below).
Thanks for all these links, they are very instructive. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Minimizing-Dependencies-within-Generic-Cl... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Sun, Nov 14, 2010 at 13:06, viboes <vicente.botet@wanadoo.fr> wrote:
Dan Tsafrir wrote:
I believe this very issue was addressed and solved by the committee. Specifically, the allocator proposal (which got accepted to c++0x) was revised to include the following paragraph (see p. 5 of [2]):
"The key requirements for an allocator’s pointer type are that it has pointer-like syntax (i.e., it can be dereferenced using operator*), that it is implicitly convertible to the corresponding void_pointer and explicitly convertible from the corresponding void_pointer, and that there exists a specialization of the pointer_traits class template, which describes a number of key attributes of the pointer type. If an allocator does not define a pointer type, allocator_traits will provide default types for pointer, const_pointer, void_pointer, and const_void_pointer of value_type*, const value*, void*, and const void*, respectively. The above pointer requirements were carefully crafted to be harmonious with the intent of N2913 (SCARY Iterator Assignment and Initialization)."
The SCARY proposal was synchronously revised to allow the iterator to depend upon the types X::allocator_type::const_void_pointer and X::allocator_type::void_pointer (where X is a container) thereby ridding programmers from the need to depend on the allocator type (see [3]).
From what I read this should answer I question I posted in this thread. It seems that the C++0x proposal is taking in account this technique seriously. Does C++0x proposal requires SCARY implementations for containers?
SCARY generated quite a controversy because on the one hand it was backed by key figures but on the other hand it was proposed very late in the standardization process; specifically, the committee convener strongly objected to SCARY, arguing that dealing with this issue so late in the process is unacceptable (search for occurrences of "scary" in [1] to see the discussion). It was eventually decided to postpone SCARY to the next C++ revision (c++1y?), and the issue has been assigned with a "NAD Future" status (search for "scary" in [2]). Best, --Dan [1] "Minutes of WG21 Meeting, October 19, 2009", committee paper N3003 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3003.pdf [2] "C++ Standard Library Issues List" http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html
----- Original Message ----- From: "Joaquin M Lopez Munoz" <joaquin@tid.es> To: <boost@lists.boost.org> Sent: Saturday, November 13, 2010 1:37 PM Subject: Re: [boost]Minimizing Dependencies within Generic Classes for Faster and Smaller Programs
3. With these caveats, Boost.MultiIndex iterators can be said to be SCARY as long as they belong to the same category of index (ordered, hashed, sequenced, random.access) in some situations, not in others. <snip> but the following, which would be far more useful, does *not* work:
// example 2
typedef multi_index_container< int, indexed_by< ordered_unique<identity<int> >, ordered_non_unique<identity<int>,std::greater<int> >
multi_t;
multi_t::nth_index<0>::type::iterator it1; multi_t::nth_index<1>::type::iterator it2;
it1=it2;
I can see the utility of these kind of assignments, but I would not name them SCARY, as the types are different. I find however enough clear the approach you take in Boost.MultiIndex to achieve the same behavior via projections http://www.boost.org/doc/libs/1_44_0/libs/multi_index/doc/tutorial/basics.ht... Best, Vicente
participants (10)
-
Andy Venikov -
Dan Tsafrir -
Dan Tsafrir -
Daniel James -
Dean Michael Berris -
Felipe Magno de Almeida -
Ion Gaztañaga -
Joaquin M Lopez Munoz -
viboes -
vicente.botet