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.