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
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to