Re: [boost] Minimizing Dependencies within Generic Classes for Faster and Smaller Programs

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 [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-Classes-for-Faster-and-Smaller-Programs-tp3036461p3041619.html
Sent from the Boost - Dev mailing list archive at Nabble.com.