c++14

When using auto&& to handle a function returning an lvalue: int func() { int v=42; return v; } auto && v = func(); What are the consequences of treating v as a reference instead of an lvalue? Do these consequences justify the use of decltype(auto) instead of auto&& to perform generic handling of function's return type? auto&& is already optimal for capturing function return values, such that the differences of decltype(auto) can only be disadvantages. In your example, lifetime extension is applied to the otherwise-temporary object returned from the function. This causes it to behave

In the C++14 standard § 5.1.2/12 it shows an example of a lambda expression that apparently seems to be able to refer to a reaching scope's variable x , even though: the capture list is empty, i.e. no capture-default the comment says that it "does not capture x " Here's the example: void f(int, const int (&)[2] = {}) { } // #1 void test() { const int x = 17; auto g = [](auto a) { f(x); // OK: calls #1, does not capture x }; } See that it does compile . It seems to hinge on x being const ; if the const is removed, it no longer compiles for the reasons one would expect (capture list is empty).

Currently, only doubles can produce a template of chars in a user defined literal: template <char...> double operator "" _x(); // Later 1.3_x; // OK "1.3"_y; // C++14 does not allow a _y user- // defined operator to parse that as a template of chars Is there a clever way to produce a std::integer_sequence of chars using a user defined literal. In other words, what the code of _y(const char*, std::size_t) would be so that I end up with a std::integer_sequence<char, '1', '.', '3'> ? At this point in time, the best we can (portably) do is a macro trick as demonstrated for vtmpl::string .

Is there actually any reason to use the following syntax anymore : template<typename T> auto access(T& t, int i) -> decltype(t[i]) { return t[i]; } Now that we can use : template<typename T> decltype(auto) access(T& t, int i) { return t[i]; } The trailing return type syntax now seems a little redundant? Deduced return types are not SFINAE friendly. This overload will simply drop out of the overload set if t[i] is invalid: template<typename T> auto access(T& t, int i) -> decltype(t[i]) { return t[i]; } Whereas this overload will not, leading to a hard error: template<typename T> decltype(auto)

On cppreference there is a mentioning that one can have templated user-literal operators, with some restrictions: If the literal operator is a template, it must have an empty parameter list and can have only one template parameter, which must be a non-type template parameter pack with element type char , such as template <char...> double operator "" _x(); So I wrote one like in the code below: template <char...> double operator "" _x() { return .42; } int main() { 10_x; // empty template list, how to specify non-empty template parameters? } Question: The code works, but how can I use the

Why does the following code fail to compile? Even though it is legal to do void* ptr = 0; template <void* ptr = 0> void func(); int main() { func(); return 0; } I ask because I found that a very trusted source did something similar and it failed to compile on my machine NOTE Should have posted the compiler error along with my question so here it is so_test.cpp:1:23: error: null non-type template argument must be cast to template parameter type 'void *' template <void* ptr = 0> ^ static_cast<void *>( ) so_test.cpp:1:17: note: template parameter is declared here template <void* ptr = 0> ^ so

Note: This question is really close to Return type deduction for in-class friend functions , but I did not find the answer to my problem there. Tested with clang 3.4 with std=c++1y and clang 3.5 with std=c++14 and std=c++1z This code compiles: #include <iostream> template<class T> class MyClass { public: MyClass(T const& a) : impl(a) {} template<class T0, class T1> friend auto // requires operator+(T0,T1) exists operator+(MyClass<T0> const& a, MyClass<T1> const& b) { return MyClass<decltype(a.impl+b.impl)>{a.impl + b.impl}; } T getImpl() const { return impl; } private: T impl; }; int main() {

Does standard C++11 guarantee that std::async(std::launch::async, func) launches function in separate thread? Working Draft, Standard for Programming Language C++ 2016-07-12: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4606.pdf 1. On the one hand , C++11-Standard says that if the thread can not be created, then there is an error. This ensures the creation of a new thread (in the absence of errors). § 30.6.8 6 Throws: system_error if policy == launch::async and the implementation is unable to start a new thread. 7 Error conditions: (7.1) — resource_unavailable_try_again — if policy

I got this example from §5.19/2 in N4140: constexpr int incr(int &n) { return ++n; } As far as I can tell, this is not a constexpr function. But the snippet compiles in clang and g++. See live example . What am I missing here? In C++14 the rules for constexpr function were relaxed and the paper N3597: Relaxing constraints on constexpr functions . The paper goes into the rationale and the effects and it includes the following ( emphasis mine ): As in C++11, the constexpr keyword is used to mark functions which the implementation is required to evaluate during translation, if they are used from