c++ - How can I write a stateful allocator in C++11, given requirements on copy construction? -

c++ - How can I write a stateful allocator in C++11, given requirements on copy construction? -

as far can tell, requirements on allocator used stl containers laid out in table 28 of section 17.6.3.5 of c++11 standard.

i'm bit confused interaction between of these requirements. given type x allocator type t, type y "the corresponding allocator class" type u, instances a, a1, , a2 of x, , instance b of y, table says:

the look a1 == a2 evaluates true if storage allocated a1 can deallocated a2, , vice versa.

the look x a1(a); well-formed, doesn't exit via exception, , afterward a1 == a true.

the look x a(b) well-formed, doesn't exit via exception, , afterward a == b.

i read saying allocators must copy-constructible in such way copies interchangeable originals. worse, same true across type boundaries. seems pretty onerous requirement; far can tell, makes impossible big number of types of allocators.

for example, had freelist class wanted utilize in allocator, in order cache freed objects. unless i'm missing something, couldn't include instance of class in allocator, because sizes or alignments of t , u might differ , hence freelist entries not compatible.

my questions:

are interpretations above correct?

i've read in few places c++11 improved back upwards "stateful allocators". how case, given these restrictions?

do have suggestions how sort of thing i'm trying do? is, how include allocated-type-specific state in allocator?

in general, language around allocators seems sloppy. (for example, prologue table 28 says assume a of type x&, of expressions redefine a.) also, @ to the lowest degree gcc's back upwards non-conformant. accounts weirdness around allocators? infrequently used feature?

1) interpretations above correct?

you right free-list might not fit allocators, need able handle multiple sizes (and alignments) fit. that's problem free-list solve.

2) i've read in few places c++11 improved back upwards "stateful allocators". how case, given these restrictions?

it not much improved, born. in c++03 instance of allocator supposed equivalent instance of same type, making stateful allocators impossible.

3) have suggestions how sort of thing i'm trying do? is, how include allocated-type-specific state in allocator?

your allocator has flexible, because not supposed know memory (and types) supposed allocate. requirement necessary insulate (the user) internals of container uses allocator.

yes, costly requirement.

4) in general, language around allocators seems sloppy. (for example, prologue table 28 says assume of type x&, of expressions redefine a.) also, @ to the lowest degree gcc's back upwards non-conformant. accounts weirdness around allocators? infrequently used feature?

the standard in general not easy read, not allocators. have careful.

to pedant, gcc not back upwards allocators (it's compiler). surmise speaking libstdc++ (the standard library implementation shipped gcc). libstdc++ old, , tailored c++03. has been adapted toward c++11, not conformant yet (still uses copy-on-write strings, example). reason libstdc++ has huge focus on binary compatibility, , number of changes required c++11 break compatibility; must hence introduced carefully.

c++ c++11 stl allocator