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: Dan Tsafrir (dants_at_[hidden])
Date: 2010-11-14 12:12:03

On Sun, Nov 14, 2010 at 13:06, viboes <vicente.botet_at_[hidden]> 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