You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently is_small disables local storage according to std::uses_allocator. If uses_allocator returns false_type and local storage is applied, then construct and destroy don't get called.
Instead, construct and destroy should be applied to the local storage. A copy of the allocator needs to be saved to call destroy, but hopefully this can be avoided.
Detect whether the allocator actually implements destroy; if not, use ordinary destruction.
If the allocator is scoped_allocator_adaptor and get_allocator() works on the target, then it would be nice to use that for destruction. But, that would be too presumptuous. It might be OK to check for implementation of destroy on scoped_allocator_adaptor::outer_allocator_type. A more generic means would be nice.
The text was updated successfully, but these errors were encountered:
potswa
changed the title
construct() and destroy() should work without uses_allocator, with local storage
construct() and destroy() should work without uses_allocator, with local storage
Sep 17, 2015
Also, erasures created without an allocator should not include std::allocator but should use ::new and ::delete instead. (This implies separate, simplified classes.)
Currently
is_small
disables local storage according tostd::uses_allocator
. Ifuses_allocator
returnsfalse_type
and local storage is applied, thenconstruct
anddestroy
don't get called.Instead,
construct
anddestroy
should be applied to the local storage. A copy of the allocator needs to be saved to calldestroy
, but hopefully this can be avoided.Detect whether the allocator actually implements
destroy
; if not, use ordinary destruction.If the allocator is
scoped_allocator_adaptor
andget_allocator()
works on the target, then it would be nice to use that for destruction. But, that would be too presumptuous. It might be OK to check for implementation ofdestroy
onscoped_allocator_adaptor::outer_allocator_type
. A more generic means would be nice.The text was updated successfully, but these errors were encountered: