c++14

问题 I am wondering what is wrong when I use *(set.find(x)) == x instead of set.find(x)!=set.end() . It usually works but while attempting a question on Hackerrank (question : link). This code gives CA for all test cases : int main() { /* Enter your code here. Read input from STDIN. Print output to STDOUT */ set<int>s; int n,x,y; cin >> n; while(n--){ cin >> y >> x; if(y==1) s.insert(x); else if(y==2) s.erase(x); else { set<int>::iterator it=s.find(x); if(it != s.end()) cout << "Yes" <<endl; else

问题 I had nested partially specialized template code working with VS 2015 until I discovered that it was not standards-compliant. I want it to be so I twisted my code to overcome the former issue and also that one and have now hit a hard wall. Using variadic templates and partial specialization I would like to fill an array at compile-time given a fixed set of parameters. What I want to achieve also seems similar to this answer but I did not manage to make it work. Consider the following program:

问题 I'm looking through n3690 , a draft of the upcoming C++14 standard, and I see in section 7.2 paragraph 9 : Two enumeration types are layout-compatible if they have the same underlying type. However, I can't find anything that says an enumeration type is layout-compatible with its underlying type. To me it seems obvious that this should follow given the reasonable semantics for what "underlying type" means, but is it actually guaranteed by the standard? 回答1: NO, there is no black-letter quote

问题 Given a (reduced) implementation of the detection idiom namespace type_traits { template<typename... Ts> using void_t = void; namespace detail { template<typename, template<typename...> class, typename...> struct is_detected : std::false_type {}; template<template<class...> class Operation, typename... Arguments> struct is_detected<void_t<Operation<Arguments...>>, Operation, Arguments...> : std::true_type {}; } template<template<class...> class Operation, typename... Arguments> using is

问题 I'm trying to do the following: #include <iostream> #include <vector> #include <tuple> #include <list> template <typename T> void f(T t) { std::cout << "1" << std::endl; } template <typename T, typename V> void f(T<std::tuple<V>> t) { std::cout << "2" << std::endl; } int main() { f(std::list<double>{}); // should use first template f(std::vector<std::tuple<int>>{}); // should use second template } What is the simplest way to do this in C++14? I thought that I could sort of pattern match in

问题 Who owns the shared state in futures and promises? In particular who is responsible for the construction and deletion of the shared state in these classes? Or is the shared state supposed to be reference counted? I am not able to get an answer by reading the docs for these on cppreference. The way I was thinking about it the easiest thing to do would be to have the std::promise class be responsible for the creation of the shared state, but then hand it off to the std::future that is fetched

问题 Consider the following code: int main() { auto l = [](auto){}; void(*p)(int) = l; } It works just fine both with GCC and clang. Let's consider the following slightly modified version: int main() { auto l = [](auto...){}; void(*p)(int) = l; } In this case, clang still accepts it while GCC rejects it. Is there any reason for which this code should be rejected or is it a bug of the compiler? I'm going to open an issue, but I'd like to know if there exists any proposal that could have been

问题 The code below doesn't compile under GCC 5.3.0 because the declaration of r is missing a constexpr specifier. const int i = 1; const int& r = i; constexpr int j = r; I believe the rejection is correct. How do I prove it using the working draft N4527? 回答1: First, since we're using a reference, [expr.const]/(2.9) must not be violated. (2.9.1) applies, though: an id-expression that refers to a variable or data member of reference type unless the reference has a preceding initialization and

问题 The standard working draft (n4582, 20.6.3, p.552) states the following suggestion for implementations of std::any : Implementations should avoid the use of dynamically allocated memory for a small contained object. [ Example: where the object constructed is holding only an int. —end example ] Such small-object optimization shall only be applied to types T for which is_nothrow_move_constructible_v is true. As far as I know, std::any can be easily implemented through type erasure/virtual

问题 Let's say I have two arithmetic types, an integer one, I , and a floating point one, F . I also assume that std::numeric_limits<I>::max() is smaller than std::numeric_limits<F>::max() . Now, let's say I have a positive integer value i . Because the representable range of F is larger than I , F(i) should always be defined behavior. However, if I have a floating point value f such that f == F(i) , is I(f) well defined? In other words, is I(F(i)) always defined behavior? Relevant section from