c++14

问题 I have compilers disagreeing on a small C++14 code snippet: #include <cassert> struct unmovable { unmovable() {} unmovable(unmovable&&) = delete; }; int main() { unmovable u; auto i = [&]() -> decltype(auto) { return u; }; auto& uu = i(); assert(&uu == &u); } The program is accepted by g++4.9.3, g++-5.1.0, g++-5.2.0 and VisualStudio 2015, but not by clang++-3.7. clang++-3.7 deduces the return type to be unmovable (value) and not unmovable& . If the program is changed slightly, so that the

问题 ideone example I need to forward some predefined arguments plus some user-passed arguments to a member function. #define FWD(xs) ::std::forward<decltype(xs)>(xs) template<class T, class... Ts, class... TArgs> void forwarder(void(T::*fptr)(Ts...), TArgs&&... xs) { T instance; (instance.*fptr)(FWD(xs)..., 0); // ^ // example predefined argument } forwarder(&example::f0, 10, 'a'); forwarder(&example::f1, 10, "hello", 5); This works properly for non-template member functions. The member function

问题 I have several std::unordered_maps . They all have an std::string as their key and their data differs. I want to make a csv string from a given map's keys because that data needs to be sent over the wire to a connected client. At the moment I have a method for each individual map. I wanted to make this generic and I came up with the following : std::string myClass::getCollection(auto& myMap) { std::vector <std::string> tmpVec; for ( auto& elem : myMap) { tmpVec.push_back(elem.first); } std:

问题 I am trying to better understand a rather surprising discovery regarding unions and the common initial sequence rule. The common initial sequence rule says (class.mem 23):  In a standard-layout union with an active member of struct type T1, it is permitted to read a non-static data member m of another union member of struct type T2 provided m is part of the common initial sequence of T1 and T2; the behavior is as if the corresponding member of T1 were nominated. So, given: struct A { int a;

问题 C++14 has rules for what you can and can't do in a constexpr function. Some of them (no asm , no static variables) seem pretty reasonable. But the Standard also disallows goto in constexpr functions, even while it allows other control flow mechanisms. What's the reasoning behind this distinction? I thought we were past " goto is hard for compilers ". 回答1: My understanding is there was a desire to get relaxed constexpr semantics in C++14. A lot of the restrictions that were relaxed were

问题 Is there a way to write a variant of std::tie in c++11/1y that ties deeply into a tuple. That is, one in which tie((x,y),z) = make_tuple(make_tuple(1,2),3) binds x, y, z to 1, 2 and 3 , respectively as in the following example. It would be nice. Thanks. #include <tuple> #include <iostream> using namespace std; int main() { int x, y ,z; auto t = make_tuple(1,2); std::tie(y,x)= t; //std::tie((x,y),z) = make_tuple(t,3); //not working cout << x << y << z << endl; return 0; } 回答1: Maybe you're

问题 To demo move semantics, I wrote the following example code, with an implicit constructor from int. struct C { int i_=0; C() {} C(int i) : i_( i ) {} C( const C& other) :i_(other.i_) { std::cout << "A copy construction was made." << i_<<std::endl; } C& operator=( const C& other) { i_= other.i_ ; std::cout << "A copy assign was made."<< i_<<std::endl; return *this; } C( C&& other ) noexcept :i_( std::move(other.i_)) { std::cout << "A move construction was made." << i_ << std::endl; } C&

问题 I'm trying to parse a list of numbers into a fixed sized std::array container using boost::spirit's newest release x3 (as included in boost 1.54). Since std::array has the necessary functions, it is detected as an Container, but it is lacking the insert function which makes it incompatible. Here is a short example of what I am trying to accomplish: #include <boost/spirit/home/x3.hpp> #include <array> #include <iostream> #include <string> namespace x3 = boost::spirit::x3; namespace ascii =

问题 I feel certain it must be possible to use SFINAE (possibly with Macros) to static_assert() that arbitary code will not compile. There are some complex cases in my code-base, where i have a class that I want to forbid taking temporaries (I believe the pattern is): class(const class&& tmp)=delete; /* deny copying from an unnamed temporary */ class (class&& rhs){/* allow construction from non-temporary rvalue*/} Currently, I check an undesired constructor DOES NOT compile, but then of course I

问题 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? 回答1: 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]) {