Don't Help the Compiler
Why Stack Overflow recommends it
Stack Overflow users link it as the canonical explanation of why explicit template arguments, std::move on returns and const returns usually hurt rather than help.
Recommended by 4 people across 3 different months, 2013 to 2020.
What it is
A 77-minute Going Native 2013 talk by Stephan T. Lavavej (STL) on how C++ programmers should work with the compiler instead of trying to outsmart it. It covers lifetime, rvalueness and types, using examples from C++98 through C++14, including make_pair, return value optimization and move semantics.
What people said
Strong rec sehe · 2017-11 · Stack Overflow · on “does boost-1.55 boost::property_tree::ptree compile with c++11?”
If you have time for an excellent talk, listen to Stephan Lavavej explain why doing `std::make_pair ` is ***not*** the solution you want to do "Don't Help The Compiler" 48:42 [this video] . He also explains some of the changes to `std::pair` and `std::make_pair` in c++11
Recommends Othman Benchekroun · 2015-06 · Stack Overflow · on “Template class optimizations during compiling”
Do not try to help the compiler : [this video] , not a direct answer to your question but still should know about this.
Recommends Qaz · 2016-07 · Stack Overflow · on “Why the following code compiles with `c++03` but not with `c++11`”
The error message gives you a clue: unresolved overloaded function type You pass in std::deque::push_back . Looking at a reference [LINK] , you can see there are two overloads: void push_back( const T& value ); void push_back( T&& value ); // (since C++11) C++11 added a new overload. Therefore, passing a pointer to this as an argument becomes invalid. Likewise for push_front . Note that even before C++11, implementations are allowed to add their own overloads [citation needed] . You can cast it to the appropriate type: .def("push_back" ,static_cast<void(DequeUInt64::*)(DequeUInt64::const_reference)>(&DequeUInt64::push_back)) .def("push_front" ,static_cast<void(DequeUInt64::*)(DequeUInt64::co
Recommends Benjamin Lindley · 2017-11 · Stack Overflow · on “Insert unique_ptr in vector as pair”
Don't pass template arguments to std::make_pair . Just let them be deduced. See this video(link) [this video] by Steven Lavavej. (thanks to Passer By for finding the link) std::pair<std::unique_ptr<CEdit>, CRect> pair = std::make_pair(std::move(edit), rectEdit); std::vector does not have a function named insert [LINK] that only takes one argument. You have to pass an iterator for a position. Perhaps you were looking for push_back ? m_editCtrls.push_back(std::make_pair(std::move(edit), rectEdit)); Or even better, emplace_back . m_editCtrls.emplace_back(std::move(edit), rectEdit);
Cites Ralph Tandetzky · 2013-10 · Stack Overflow · on “Why does std::move prevent RVO (return value optimization)?”
The cases where copy and move elision is allowed is found in section 12.8 §31 of the Standard (version N3690): When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the constructor selected for the copy/move operation and/or the destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization. This elision of copy/move operations, called copy elision
Cites tach · 2013-10 · Stack Overflow · on “Efficient accumulate”
Assume I have vector of strings and I want concatenate them via std::accumulate. If I use the following code: std::vector<std::string> foo{"foo","bar"}; string res=""; res=std::accumulate(foo.begin(),foo.end(),res, [](string &rs,string &arg){ return rs+arg; }); I can be pretty sure there will be temporary object construction. In this [LINK] answer they say that the effect of std::accumulate is specified this way: Computes its result by initializing the accumulator acc with the initial value init and then modifies it with acc = acc + *i or acc = binary_op(acc, *i) for every iterator i in the range [first,last) in order. So I'm wondering what is the correct way to do this to avoid the unnecess
Cites Surt · 2014-09 · Stack Overflow · on “Will returning a const object from a function prevent move construction from outside?”
Angew's answer is right but who can remember all the language lawyer rules? To help me remember it easier I wrote the following rules which came from STL's own mouth. Don't return locals as const [16] $ Inhibits move semantics Don't use move when returning local by value of exact same type [16] $ NVRO won't be used if you do this. Don't return by Rvalue reference (&&) [16] $ Unless you really really know what you're doing. Notes: [16] Don't Help the Compiler, Going Native 2013, [this video]
Cites David Schwartz · 2015-03 · Stack Overflow · on “How to maximize the use of the number 0 to optimize a program”
When I click on the linked video, the first recommended video on the right is, by the same author, Don't help the compiler [this video] .
Cites Rostislav · 2015-08 · Stack Overflow · on “Using reference-to-lambda as comparator in a map (the right way?)”
I want to use a lambda as a custom comparator in a std::map but unfortunately Visual Studio 2013 compiler does not allow using a simple code like that: auto cmp = [](int l, int r) { return l < r; }; std::map<int, int, decltype(cmp)> myMap(cmp); myMap[1] = 1; and fails with error C3497: you cannot construct an instance of a lambda Seems that this code works fine in GCC 5.1 and Visual Studio 2015 (checked using ideone [LINK] and VC++ online compiler [LINK] ). But for VS2013, one of the solutions would be to use a reference as proposed here [LINK] (note auto& ): auto& cmp = [](int l, int r) { return l < r; }; std::map<int, int, decltype(cmp)> myMap(cmp); myMap[1] = 1; Clearly, GCC doesn't compi
Cites sp2danny · 2015-11 · Stack Overflow · on “Efficiently Using A Function Output”
The following: MyType someFunc() { MyType result; // produce value here return result; } Used like this: MyType var = someFunc(); Will do no copy, and no move, but rather RVO [LINK] . This means that it can't get more efficient anyway, and it is also easy to read, and hard to use wrong . Don't help the compiler [this video] .