Add static_cast<std::size_t> when comparing int to std::size_t.
Also, include <cstddef> when it wasn't already being included.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@287822 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The `max_size()` method of containers should respect both the allocator's reported `max_size` and the range of the `difference_type`. This patch makes all containers choose the smallest of those two values.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26885
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@287729 91177308-0d34-0410-b5e6-96231b3b80d8
With a max_load_factor of 1.0, the only guarantee is that
bucket_count() >= size(). (Note: setting max_load_factor without
rehashing isn't supposed to affect this, because setting
max_load_factor is currently specified to be constant time.)
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@286982 91177308-0d34-0410-b5e6-96231b3b80d8
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:
This patch attempts to fix the undefined behavior in __tree by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).
The UB in `__tree` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 3 node types in __tree.
* `__tree_end_node` which contains the `__left_` pointer. This node is embedded within the container.
* `__tree_node_base` which contains `__right_`, `__parent_` and `__is_black`. This node is used throughout the tree rebalancing algorithms.
* `__tree_node` which contains `__value_`.
Currently `__tree` stores the start of the tree, `__begin_node_`, as a pointer to a `__tree_node`. Additionally the iterators store their position as a pointer to a `__tree_node`. In both of these cases the pointee can be the end node. This is fixed by changing them to store `__tree_end_node` pointers instead.
To make this change I introduced an `__iter_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node` in the current one.
Both `__tree::__begin_node_` and iterator pointers are now stored as `__iter_pointers`.
The other situation where `__tree_end_node` is stored as the wrong type is in `__tree_node_base::__parent_`. Currently `__left_`, `__right_`, and `__parent_` are all `__tree_node_base` pointers. Since the end node will only be stored in `__parent_` the fix is to change `__parent_` to be a pointer to `__tree_end_node`.
To make this change I introduced a `__parent_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node_base` in the current one.
Note that in the new ABI `__iter_pointer` and `__parent_pointer` are the same type (but not in the old one). The confusion between these two types is unfortunate but it was the best solution I could come up with that maintains the ABI.
The typedef changes force a ton of explicit type casts to correct pointer types and to make current code compatible with both the old and new pointer typedefs. This is the bulk of the change and it's really messy. Unfortunately I don't know how to avoid it.
Please let me know what you think.
Reviewers: howard.hinnant, mclow.lists
Subscribers: howard.hinnant, bbannier, cfe-commits
Differential Revision: https://reviews.llvm.org/D20786
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@276003 91177308-0d34-0410-b5e6-96231b3b80d8
