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

752. Allocator complexity requirement

Section: 16.4.4.6 [allocator.requirements] Status: C++11 Submitter: Hans Boehm Opened: 2007-10-11 Last modified: 2016-01-28

Priority: Not Prioritized

View other active issues in [allocator.requirements].

View all other issues in [allocator.requirements].

View all issues with C++11 status.

Discussion:

Did LWG recently discuss 16.4.4.6 [allocator.requirements]-2, which states that "All the operations on the allocators are expected to be amortized constant time."?

As I think I pointed out earlier, this is currently fiction for allocate() if it has to obtain memory from the OS, and it's unclear to me how to interpret this for construct() and destroy() if they deal with large objects. Would it be controversial to officially let these take time linear in the size of the object, as they already do in real life?

Allocate() more blatantly takes time proportional to the size of the object if you mix in GC. But it's not really a new problem, and I think we'd be confusing things by leaving the bogus requirements there. The current requirement on allocate() is generally not important anyway, since it takes O(size) to construct objects in the resulting space. There are real performance issues here, but they're all concerned with the constants, not the asymptotic complexity.

Proposed resolution:

Change 16.4.4.6 [allocator.requirements]/2:

-2- Table 39 describes the requirements on types manipulated through allocators. All the operations on the allocators are expected to be amortized constant time. Table 40 describes the requirements on allocator types.