Deleted move members are evil. They are not outlawed, because some day, someone will find a clever use for them. But I haven’t seen a good use yet. Deleting a special member is not the same thing as not having a special member. Nowhere is this more obvious than with the move constructor and move … Read more
If you define the assignment operator to take a value, you should not (need not and cannot) define the assignment operator taking an rvalue-reference. There is no point to it. In general, you only need to provide an overload taking an rvalue-reference when you need to differentiate an lvalue from an rvalue, but in this … Read more
Short answer: because the Standard says so. Longer answer: prior to Standardization, C++ templates required the class keyword for all template parameters. However, to stress the fact that templates could also be of non-class (i.e. builtin) type, an alternative keyword typename was introduced. However, in C++98, template-template parameters could only be of class-type, and this … Read more
Unfortunately, they don’t know what delete to use therefore they use delete. That’s why for each smart pointer we have a smart array counterpart. std::shared_ptr uses delete std::shared_array uses delete[] So, your line std :: unique_ptr <int> x (new int [2]); actually causes undefined behavior. Incidentally, if you write std :: unique_ptr<int[]> p(new int[2]); ^^ … Read more
template<class Y> explicit shared_ptr(Y* p); [util.smartptr.shared.const]/6 Throws: bad_alloc, or an implementation-defined exception when a resource other than memory could not be obtained. [util.smartptr.shared.const]/7 Exception safety: If an exception is thrown, delete p is called. So no, no memory leak.
You have to use auto using fp = auto (*)(int) -> int; typedef auto (*fp)(int) -> int; // alternatively Trailing return type syntax means you put the auto before the function name to indicate that the return type follows (or in the case of c++14, should be deduced). For function pointers, the same rule applies … Read more
Short answer: no. Long answer: nope. It should be noted that C++14‘s support for transparent comparators eliminates the need for Boost.Bimap 90% of the time*: when you need to key off of any given property of an object (stored or computed), often a simple, bitwise-comparable unique identifier inherent to/present in the object anyway. With transparent … Read more
The standard does not specify whether a closure type (the type of a lambda expression) is trivial or not. It explicitly leaves this up to implementation, which makes it non-portable. I am afraid you cannot rely on your static_assert producing anything consistent. Quoting C++14 (N4140) 5.1.2/3: … An implementation may define the closure type differently … Read more
Yes, sure. Normal name lookup rules apply. [expr.prim.lambda]/7 … for purposes of name lookup … the compound-statement is considered in the context of the lambda-expression. Re: why local variables are treated differently from global ones. [expr.prim.lambda]/13 … If a lambda-expression or an instantiation of the function call operator template of a generic lambda odr-uses (3.2) … Read more
C++11 provides us with std::condition_variable. In your timer you can wait until your condition has been met: // Somewhere else, e.g. in a header: std::mutex mutex; bool condition_to_be_met{false}; std::condition_variable cv; // In your timer: // … std::unique_lock<std::mutex> lock{mutex}; if(!cv.wait_for(lock, std::chrono::milliseconds{timeout_ms}, [this]{return condition_to_be_met;})) std::cout << “timed out!” << std::endl; You can find more information here: https://en.cppreference.com/w/cpp/thread/condition_variable … Read more