c++14

Given an std::tuple -like object (i.e. with defined tuple_size and get semantics) and a unary functor object ftor , I want to be able to call ftor on each element of the tuple -like object. If I disregard the return value, I am aware of the int array trick: namespace details { template <typename Ftor, typename Tuple, size_t... Is> void apply_unary(Ftor&& ftor, Tuple&& tuple, std::index_sequence<Is...>) { using std::get; int arr[] = { (ftor(get<Is>(std::forward<Tuple>(tuple))), void(), 0)... }; } } // namespace details template <typename Ftor, typename Tuple> void apply_unary(Ftor&& ftor, Tuple

Why does std::runtime_error not provide a constructor accepting an std::string&& ? Looking at the constructors for std::string , it has a move constructor, but the noexcept specification is only there for C++14, not C++11. Was this a mistake, a deadline that was missed or am I missing something? explicit runtime_error(string&&); does not exist simply because it would not provide any optimization. As it turns out, a C++11-conforming runtime_error does not internally store a std::string . The reason is that the copy members of runtime_error must not throw exceptions. Otherwise the wrong

Please consider this code: class A { }; int main() { std::vector<A> test; test.push_back(A()); } The constructor and destructor will be called twice, also memory will be allocated twice and the object will copied, now not only is that potentially bad for performance it could also lead to run time errors, especially if there's some cleanup going on in the destructor. The way i'd usually get around this is to just create a vector of pointers instead : std::vector<A*> test; test.push_back(new A()); My question is two fold, is this common practice and is it good practice? Or is there a better way?

I am struggling to understand why the following code does not allow an implicit conversion to occur. #include <string> using namespace std; struct HasConversionToString { HasConversionToString(const string& s_) : s{s_} {} string s; operator const string&() const { return s; } }; int main() { string s{"a"}; HasConversionToString obj{"b"}; return s < obj; } Both clang and gcc fail to find a valid way to compare the two objects with errors along the lines of: clang++ -std=c++14 -Wall -Wextra -pedantic conversion.cpp -o test conversion.cpp:13:12: error: invalid operands to binary expression (

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 pointer passed to forwarder can, however, point to template functions as well. Unfortunately, the

This is a C++ / D cross-over question. The D programming language has ranges that -in contrast to C++ libraries such as Boost.Range - are not based on iterator pairs. The official C++ Ranges Study Group seems to have been bogged down in nailing a technical specification. Question : does the current C++11 or the upcoming C++14 Standard have any obstacles that prevent adopting D ranges -as well as a suitably rangefied version of <algorithm> - wholesale? I don't know D or its ranges well enough, but they seem lazy and composable as well as capable of providing a superset of the STL's algorithms.

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::stringstream ss; for ( auto& elem : tmpVec ) { ss << elem <<','; } std::string result=ss.str(); result

I've spent quite a few hours today trying to understand why this code segfaults on g++6.2 and g++7.0 , while happily working as intended on clang++3.9 (and 4.0 ) . I reduced the issue to a 85 lines self-contained code snippet , which does not segfault upon normal execution, but always reports an error under UBSAN. The issue is reproducible on wandbox , by compiling with g++7 , enabling optimizations and passing -fsanitize=undefined as an extra flag. This is what UBSAN reports: prog.cc: In function 'int main()': prog.cc:61:49: warning: 'ns#0' is used uninitialized in this function [

What is the difference between decltype(auto) and decltype(returning expression) as return type of a function (template) if expr used without parentheses in both cases? auto f() -> decltype(auto) { return expr; } // 1 auto f() -> decltype(expr) { return expr; } // 2 Above f can be defined/declared in any context and can be either (member) function or (member) function template, or even (generic) lambda. expr can depend on any template parameters. In second version both expr are exactly the same expression without extra parentheses. Which differences can one expect, using first or second form