Subject: Re: [boost] Minimizing Dependencies within Generic Classes for Faster and Smaller Programs
From: viboes (vicente.botet_at_[hidden])
Date: 2010-11-14 06:06:56
Dan Tsafrir wrote:
> On Nov 13, 2:37Â pm, Joaquin M Lopez Munoz <joaq..._at_[hidden]> 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 )
> 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
>> 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 ):
> "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 ).
>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
> The mailing list thread in  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.
-- View this message in context: http://boost.2283326.n4.nabble.com/Minimizing-Dependencies-within-Generic-Classes-for-Faster-and-Smaller-Programs-tp3036461p3041619.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk