Boost logo

Boost :

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 (, 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
>> 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

> 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.

View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at