Summary:
To quote STL the problems with stack allocator are"
>"stack_allocator<T, N> is seriously nonconformant to N4582 17.6.3.5 [allocator.requirements].
> First, it lacks a rebinding constructor. (The nested "struct rebind" isn't sufficient.)
> Second, it lacks templated equality/inequality.
> Third, it completely ignores alignment.
> Finally, and most severely, the Standard forbids its existence. Allocators are forbidden from returning memory "inside themselves". This requirement is implied by the Standard's requirements for rebinding and equality. It's permitted to return memory from a separate buffer object on the stack, though."
This patch attempts to address all of those issues.
First, instead of storing the buffer inside the allocator I've change `stack_allocator` to accept the buffer as an argument.
Second, in order to fix rebinding I changed the parameter list from `<class T, size_t NumElements>` to `<class T, size_t NumBytes>`. This allows allocator rebinding
between types that have different sizes.
Third, I added copy and rebinding constructors and assignment operators.
And finally I fixed the allocation logic to always return properly aligned storage.
Reviewers: mclow.lists, howard.hinnant, STL_MSFT
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25154
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@283631 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Libc++ still uses per-feature configuration macros when configuring for C++11. However libc++ requires a feature-complete C++11 compiler so there is no reason to check individual features. This patch starts the process of removing the feature specific macros and replacing their usage with `_LIBCPP_CXX03_LANG`.
This patch removes the __config macros:
* _LIBCPP_HAS_NO_TRAILING_RETURN
* _LIBCPP_HAS_NO_TEMPLATE_ALIASES
* _LIBCPP_HAS_NO_ADVANCED_SFINAE
* _LIBCPP_HAS_NO_DEFAULT_FUNCTION_TEMPLATE_ARGS
* _LIBCPP_HAS_NO_STATIC_ASSERT
As a drive I also changed our C++03 static_assert to use _Static_assert if available.
I plan to commit this without review if nobody voices an objection.
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24895
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@282347 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In test/support/test_allocator.h, fix construct() to avoid moving immovable types.
This improves the allocator's conformance, and fixes compiler errors with MSVC's STL. The scenario is when the allocator is asked to construct an object of type X that's immovable (deleted copy/move ctors), but implicitly constructible from an argument type A. When perfectly forwarded, X can be (explicitly) constructed from A, and everything is fine. That's std::allocator's behavior, and the Standard's default when a user allocator's construct() doesn't exist. The previous implementation of construct() here mishandled this scenario. Passing A to this construct() would implicitly construct an X temporary, bound to (non-templated) T&&. Then construct() would attempt to move-construct X from that X temporary, but X is immovable, boom.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21094
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@272747 91177308-0d34-0410-b5e6-96231b3b80d8
The C++03 version of function tried to default construct the allocator
in the uses allocator constructors when no allocation was performed. These
constructors would fail to compile when used with allocators that had no
default constructor.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@239708 91177308-0d34-0410-b5e6-96231b3b80d8
