vsapsai added a comment.
In https://reviews.llvm.org/D48342#1152063, @EricWF wrote:
> Are there any tests which actually exercise the new behavior?
Added tests only verify we don't use memcpy erroneously. And existing tests
make sure there are no functionality regressions. But there is nothing to test
the performance improvement. Are there any recommendations for that?
================
Comment at: libcxx/include/memory:1665
+ (is_same<allocator_type, allocator<typename
_VSTD::remove_const<_SourceTp>::type> >::value
+ || is_same<allocator_type, allocator<const _SourceTp> >::value
+ || !__has_construct<allocator_type, _DestTp*, const
_SourceTp&>::value) &&
----------------
EricWF wrote:
> I'm not sure we should care about allocators for `T const`. The're all but an
> abomination.
My main goal was to avoid performance regression for
std::vector<const int> v(const_raw, const_raw + SIZE);
I'm not protecting allocators for `T const`, it just seems cheap to support
them anyway.
================
Comment at:
libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter_different_value_type.pass.cpp:13
+// template <class InputIter> vector(InputIter first, InputIter last);
+
+// Initialize a vector with a different value type. Make sure initialization
----------------
EricWF wrote:
> Can this be folded into an existing test file for the constructor it's
> targeting?
Will move to construct_iter_iter.pass.cpp. Which reminded me that I need to
make construct_iter_iter_alloc.pass.cpp and construct_iter_iter.pass.cpp more
in sync.
https://reviews.llvm.org/D48342
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
