c++14 | 易学教程

How can I store generic packaged_tasks in a container?

阅读更多关于 How can I store generic packaged_tasks in a container?

问题 I'm trying to take a 'task' in the style of std::async and store it in a container. I'm having to jump through hoops to achieve it, but I think there must be a better way. std::vector<std::function<void()>> mTasks; template<class F, class... Args> std::future<typename std::result_of<typename std::decay<F>::type(typename std::decay<Args>::type...)>::type> push(F&& f, Args&&... args) { auto func = std::make_shared<std::packaged_task<typename std::result_of<typename std::decay<F>::type(typename

different compare signature for std::upper_bound and std::lower_bound

阅读更多关于 different compare signature for std::upper_bound and std::lower_bound

问题 Here is a sample example for both std::lower_bound & std::upper_bound , notice the signature of Compare lambda being passed to them - const auto lower_x = std::lower_bound( points.begin(), points.end(), rec.min_corner.x, [](const RankedPoint &rp, const double x) { return rp.point.x < x; }); const auto upper_x = std::upper_bound( points.begin(), points.end(), rec.max_corner.x, [](const double x, const RankedPoint &rp) { return x < rp.point.x; }); What is the possible reasoning behind keeping

How could the exception specifier on move assignment operator affect that of move constructor?

阅读更多关于 How could the exception specifier on move assignment operator affect that of move constructor?

I've being testing with GCC 5.2 and clang 3.6, both in C++14 mode, and they give the same output. For the following code #include <iostream> #include <type_traits> struct S { // S& operator= (S&&) noexcept { return *this; } }; int main() { std::cout << std::is_nothrow_move_constructible<S>::value << std::is_nothrow_move_assignable<S>::value; } the result 11 is obtained. But if uncomment the move assignment operator, the output becomes 01 . How could an explicit noexcept specification on the move assignment operator possibly affect that of the move constructor? By defining the move assignment

Filling a std::array at compile time and possible undefined behaviour with const_cast

阅读更多关于 Filling a std::array at compile time and possible undefined behaviour with const_cast

问题 It is known that std::array::operator[] since C++14 is constexpr , see declaration below: constexpr const_reference operator[]( size_type pos ) const; However, it is also const qualified. This causes implications if you want to use the subscript operator of a std::array in order to assign values to your array at compile time. For example consider the following user literal: template<typename T, int N> struct FooLiteral { std::array<T, N> arr; constexpr FooLiteral() : arr {} { for(int i(0); i

When is a C++ expression well formed?

阅读更多关于 When is a C++ expression well formed?

问题 Skimming through the C++ standard I came in quite a few cases to the statement: The expression X shall be well formed. I said to my self "OK, intuitively you know what a well formed expression is, but can you give a formal explanation of what makes a C++ expression a well formed expression?". I searched a little bit and I didn't find anything that gives a formal explanation on the matter. So here's my question: Q: What are the qualitative characteristics of a well formed expression in C++?

Can static/dynamic/const/reinterpret_cast be used in unevaluated context?

阅读更多关于 Can static/dynamic/const/reinterpret_cast be used in unevaluated context?

I tried to provide structures for checking is A is (choose cast)-castable to B . All four casts would have exact same implementation, expect their names (local-macro-able definitions would be possible, but not necessary). I wrote many check-for operators structures, for example: #include <iostream> #include <type_traits> #include <string> template<class, class, class, class = void> struct is_valid_ternary_operator : std::false_type { }; template<class T, class S, class R> struct is_valid_ternary_operator <T, S, R, std::void_t<decltype(std::declval<T>() ? std::declval<S>() : std::declval<R>())>

auto, decltype(auto) and trailing return type

阅读更多关于 auto, decltype(auto) and trailing return type

Is there a difference between: template <class T> constexpr decltype(auto) f(T&& x) -> decltype(std::get<0>(std::forward<T>(x))) { return std::get<0>(std::forward<T>(x)); } and: template <class T> constexpr auto f(T&& x) -> decltype(std::get<0>(std::forward<T>(x))) { return std::get<0>(std::forward<T>(x)); } and if so, what is it, and which one should I use for perfect forwarding? kennytm Trailing return type should only be used with auto The point of decltype(auto) vs auto is to distinguish the case whether the return type should be a reference or value . But in your case the return type is

Sized Deallocation Feature In Memory Management in C++1y

阅读更多关于 Sized Deallocation Feature In Memory Management in C++1y

问题 Sized Deallocation feature has been proposed to include in C++1y. However I wanted to understand how it would affect/improve the current c++ low-level memory management ? This proposal is in N3778 , which states following about the intent of this. With C++11 , programmers may define a static member function operator delete that takes a size parameter indicating the size of the object to be deleted. The equivalent global operator delete is not available. This omission has unfortunate

Switching back and forth between Array of Structures (AoS) and Structure of Arrays (SoA)

阅读更多关于 Switching back and forth between Array of Structures (AoS) and Structure of Arrays (SoA)

问题 One feature that plays a prominent role in many of the writings on data oriented design is that there are many cases where rather than AoS (array of structs): struct C_AoS { int foo; double bar; }; std::vector<C_AoS> cs; ... std::cout << cs[42].foo << std::endl; it is more efficient to arrange one's data in SoA (struct of arrays): struct C_SoA { std::vector<int> foo; std::vector<double> bar; }; C_SoA cs; ... std::cout << cs.foo[42] << std::endl; Now what I am looking for is a solution which

move constructor for std::runtime_error

阅读更多关于 move constructor for std::runtime_error

问题 Why does std::runtime_error not provide a constructor accepting an std::string&& ? Looking at the constructors for std::string, it has a move constructor, but the noexcept specification is only there for C++14, not C++11. Was this a mistake, a deadline that was missed or am I missing something? 回答1: explicit runtime_error(string&&); does not exist simply because it would not provide any optimization. As it turns out, a C++11-conforming runtime_error does not internally store a std::string .