This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD Editorial status.

580. unused allocator members

Section: 23.2.2 [container.requirements.general] Status: NAD Editorial Submitter: Martin Sebor Opened: 2006-06-14 Last modified: 2016-01-28

Priority: Not Prioritized

View other active issues in [container.requirements.general].

View all other issues in [container.requirements.general].

View all issues with NAD Editorial status.

Duplicate of: 479

Discussion:

C++ Standard Library templates that take an allocator as an argument are required to call the allocate() and deallocate() members of the allocator object to obtain storage. However, they do not appear to be required to call any other allocator members such as construct(), destroy(), address(), and max_size(). This makes these allocator members less than useful in portable programs.

It's unclear to me whether the absence of the requirement to use these allocator members is an unintentional omission or a deliberate choice. However, since the functions exist in the standard allocator and since they are required to be provided by any user-defined allocator I believe the standard ought to be clarified to explictly specify whether programs should or should not be able to rely on standard containers calling the functions.

I propose that all containers be required to make use of these functions.

[ Batavia: We support this resolution. Martin to provide wording. ]

[ pre-Oxford: Martin provided wording. ]

[ 2009-04-28 Pablo adds: ]

N2554 (scoped allocators), N2768 (allocator concepts), and N2810 (allocator defects), address all of these points EXCEPT max_size(). So, I would add a note to that affect and re-class the defect as belonging to section 23.2.2 [container.requirements.general].

[ 2009-07 Frankfurt ]

The comment in the description of this issue that this "would be" rendered editorial by the adoption of N2257 is confusing. It appears that N2257 was never adopted.

[ 2009-10 Santa Cruz: ]

NAD Editorial. Addressed by N2982.

Proposed resolution:

Specifically, I propose to change 23.2 [container.requirements], p9 as follows:

-9- Copy constructors for all container types defined in this clause copy an allocator argument from their respective first parameters. All other constructors for these container types take an Allocator& argument (20.1.6), an allocator whose value_type is the same as the container's value_type. A copy of this argument is used for any memory allocation performed, by these constructors and by all member functions, during the lifetime of each container object. In all container types defined in this clause , the member get_allocator() returns a copy of the Allocator object used to construct the container.²⁵⁸⁾

New Footnote: This type may be different from Allocator: it may be derived from Allocator via Allocator::rebind<U>::other for the appropriate type U.

The proposed wording seems cumbersome but I couldn't think of a better way to describe the requirement that containers use their Allocator to manage only objects (regardless of their type) that persist over their lifetimes and not, for example, temporaries created on the stack. That is, containers shouldn't be required to call Allocator::construct(Allocator::allocate(1), elem) just to construct a temporary copy of an element, or Allocator::destroy(Allocator::address(temp), 1) to destroy temporaries.

[ Howard: This same paragraph will need some work to accommodate 431⁽ⁱ⁾. ]

[ post Oxford: This would be rendered NAD Editorial by acceptance of N2257. ]