Summary:
The requirement on the `Size` type passed to *_n algorithms is that it is convertible to an integral type. This means we can't use a variable of type `Size` directly. Instead we need to convert it to an integral type first. The problem is finding out what integral type to convert it to. `__convert_to_integral` figures out what integral type to convert it to and performs the conversion, It also promotes the resulting integral type so that it is at least as big as an integer. `__convert_to_integral` also has a special case for converting enums. This should only work on non-scoped enumerations because it does not apply an explicit conversion from the enum to its underlying type.
Reviewers: chandlerc, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7449
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@228704 91177308-0d34-0410-b5e6-96231b3b80d8
The comma operators in the test iterators give better error messages when they
are deleted as opposed to not defined. Delete these functions when possible.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@220715 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
An evil user might overload operator comma. Use a void cast to make sure any user overload is not selected.
Modify all the test iterators to define operator comma.
Reviewers: danalbert, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5929
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@220706 91177308-0d34-0410-b5e6-96231b3b80d8
Things done in this patch:
1. Make __debug include __config since it uses macros from it.
2. The current method of defining _LIBCPP_ASSERT is prone to redefinitions. Move
the null _LIBCPP_ASSERT definition into the __debug header to prevent this.
3. Remove external <__debug> include gaurds. <__debug> guards almost all of its
contents internally. There is no reason to be doing it externally.
This patch should not change any functionality.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@215332 91177308-0d34-0410-b5e6-96231b3b80d8
std::make_heap is currently implemented by iteratively applying a
siftup-type algorithm. Since sift-up is O(ln n), this gives
std::make_heap a worst case time complexity of O(n ln n).
The C++ standard mandates that std::make_heap make no more than O(3n)
comparisons, this makes our std::make_heap out of spec.
Fix this by introducing an implementation of __sift_down and switch
std::make_heap to create the heap using it.
This gives std::make_heap linear time complexity in the worst case.
This fixes PR20161.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@213615 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC-specific, MSVCRT-specific, or Windows-specific. Because Clang can
also define _MSC_VER, and MSVCRT is not necessarily the only C runtime,
these macros should not be used interchangeably.
This patch divides all Windows-related bits into the aforementioned
categories. Two new macros are introduced:
- _LIBCPP_MSVC: Defined when compiling with MSVC. Detected using
_MSC_VER, excluding Clang.
- _LIBCPP_MSVCRT: Defined when using the Microsoft CRT. This is the default
when _WIN32 is defined.
This leaves _WIN32 for code using the Windows API.
This also corrects the spelling of _LIBCP_HAS_IS_BASE_OF to _LIBCPP_HAS_IS_BASE_OF.
Nico, please prepare a patch for CREDITS.TXT, thanks.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@187593 91177308-0d34-0410-b5e6-96231b3b80d8
rotate is a critical algorithm because it is often used by other algorithms,
both std and non-std. The main thrust of this optimization is a specialized
algorithm when the 'distance' to be shifted is 1 (either left or right). To my
surprise, this 'optimization' was not effective for types like std::string.
std::string favors rotate algorithms which only use swap. But for types like
scalars, and especially when the sequence is random access, these new
specializations are a big win. If it is a vector<size_t> for example, the
rotate is done via a memmove and can be several times faster than the gcd
algorithm.
I'm using is_trivially_move_assignable to distinguish between types like int and
types like string. This is obviously an ad-hoc approximation, but I haven't
found a case where it doesn't give good results.
I've used a 'static if' (with is_trivially_move_assignable) in three places.
Testing with both -Os and -O3 showed that clang eliminated all code not be
executed by the 'static if' (including the 'static if' itself).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@161247 91177308-0d34-0410-b5e6-96231b3b80d8
