The National Bodies from Spain and US have proposed to change back to the {} syntax because (P0488R0): The “structured bindings” proposal originally used braces “{}” to delimit binding identifiers. Those delimiters were changed to brackets “[]” under the assertion that they didn’t introduce any syntactic problem. However, they turned out to introduce syntactic ambiguity … Read more
Yes it can be done without a problem. All you need is a little assembly code to move the call stack to a newly allocated stack on the heap. I would look at the boost::coroutine library. The one thing that you should watch out for is a stack overflow. On most operating systems overflowing the … Read more
The problem is that std::string_view -> std::string makes a copy of the underlying memory, complete with heap allocation, whereas the implicit std::string -> std::string_view does not. If you’ve bothered to use a std::string_view in the first place then you obviously care about copies, so you don’t want one to happen implicitly. Consider this example: void … Read more
This seems to be related to CWG issue #1980 (credits to T.C. for correcting me). As a workaround you can define void_t as: template<typename… Ts> struct make_void { typedef void type;}; template<typename… Ts> using void_t = typename make_void<Ts…>::type; (from cppreference) live example on wandbox
It is possible to detect if a given function-call expression is a constant expression, and thereby select between two different implementations. Requires C++14 for the generic lambda used below. (This answer grew out this answer from @Yakk to a question I asked last year). I’m not sure how far I’m pushing the Standard. This is … Read more
There is a rule that partial specializations have to be more specialized than the primary template – both of your specializations follow that rule. But there isn’t a rule that states that partial specializations can never be ambiguous. It’s more that – if instantiation leads to ambiguous specialization, the program is ill-formed. But that ambiguous … Read more
Clang seems to be in the right. When accessing a static member with the member access syntax [class.static/1]: A static member s of class X may be referred to using the qualified-id expression X::s; it is not necessary to use the class member access syntax to refer to a static member. A static member may … Read more
This depends on whether the enclosing array object is a complete object, and if not, whether you can validly access more bytes through a pointer to that enclosing array object (e.g., because it’s an array element itself, or pointer-interconvertible with a larger object, or pointer-interconvertible with an object that’s an array element). The “reachable” requirement … Read more
This is gcc bug 80871. The issue is, we end up with this set of candidates for deduction: template <class… Types, class… Args> list<Types…> __f(Args… ); // constructor template <class… Args> list<Args…> __f(Args… ); // deduction-guide Both are valid (Types… can deduce as empty in the first case), but the call here should be ambiguous … Read more
From the proposal that suggested its deprecation: As an aid to writing iterator classes, the original standard library supplied the iterator class template to automate the declaration of the five typedefs expected of every iterator by iterator_traits. This was then used in the library itself, for instance in the specification of std::ostream_iterator: template <class T, … Read more