With the new standard, there are new ways of doing things, and many are nicer than the old ways, but the old way is still fine. It's also clear that the new standard doesn't officially deprecate very much, for backward compatibility reasons. So the question that remains is:
What old ways of coding are definitely inferior to C++11 styles, and what can we now do instead?
In answering this, you may skip the obvious things like "use auto variables".
final specifier to prevent class derivationstd::auto_ptr works are no longer needed due to first-class support for rvalue references.shrink_to_fit() member function, which should eliminate the need swapping with a temporary.= delete syntax is a much more direct way of saying that a particular functionality is explicitly denied. This is applicable to preventing heap allocation (i.e., =delete for member operator new), preventing copies, assignment, etc.result_of: Uses of class template result_of should be replaced with decltype. I think result_of uses decltype when it is available.NULL should be redefined as nullptr, but see STL's talk to learn why they decided against it.I think I'll stop there!
result_of from the list. Despite the cumbersome typename needed before it, I think typename result_of<F(Args...)::type can sometimes be easier to read than decltype(std::declval<F>()(std::declval<Args>()...), and with the acceptance of N3436 into the working paper they both work for SFINAE (which used to be an advantage of decltype that result_of didn't offer) –
Chardin At one point in time it was argued that one should return by const value instead of just by value:
const A foo();
^^^^^
This was mostly harmless in C++98/03, and may have even caught a few bugs that looked like:
foo() = a;
But returning by const is contraindicated in C++11 because it inhibits move semantics:
A a = foo(); // foo will copy into a instead of move into it
So just relax and code:
A foo(); // return by non-const value
A& operator=(A o)& instead of A& operator=(A o). These prevent the silly mistakes and make classes behave more like basic types and do not prevent move semantics. –
Herwig As soon as you can abandon 0 and NULL in favor of nullptr, do so!
In non-generic code the use of 0 or NULL is not such a big deal. But as soon as you start passing around null pointer constants in generic code the situation quickly changes. When you pass 0 to a template<class T> func(T) T gets deduced as an int and not as a null pointer constant. And it can not be converted back to a null pointer constant after that. This cascades into a quagmire of problems that simply do not exist if the universe used only nullptr.
C++11 does not deprecate 0 and NULL as null pointer constants. But you should code as if it did.
std::nullptr_t. –
Grizzled 0 or NULL for null pointers"). –
Benedictbenedicta Safe bool idiom → explicit operator bool().
Private copy constructors (boost::noncopyable) → X(const X&) = delete
Simulating final class with private destructor and virtual inheritance → class X final
One of the things that just make you avoid writing basic algorithms in C++11 is the availability of lambdas in combination with the algorithms provided by the standard library.
I'm using those now and it's incredible how often you just tell what you want to do by using count_if(), for_each() or other algorithms instead of having to write the damn loops again.
Once you're using a C++11 compiler with a complete C++11 standard library, you have no good excuse anymore to not use standard algorithms to build your's. Lambda just kill it.
Why?
In practice (after having used this way of writing algorithms myself) it feels far easier to read something that is built with straightforward words meaning what is done than with some loops that you have to uncrypt to know the meaning. That said, making lambda arguments automatically deduced would help a lot making the syntax more easily comparable to a raw loop.
Basically, reading algorithms made with standard algorithms are far easier as words hiding the implementation details of the loops.
I'm guessing only higher level algorithms have to be thought about now that we have lower level algorithms to build on.
for_each with a lambda is any better than the equivalent range-based for loop, with the contents of the lambda in the loop. The code looks more or less the same, but the lambda introduces some extra punctuation. You can use equivalents of things like boost::irange to apply it to more loops than just those that obviously use iterators. Plus the range-based for loop has greater flexibility, in that you can exit early if required (by return or by break), whereas with for_each you'd need to throw. –
Mandelbaum for makes the usual it = c.begin(), const end = c.end(); it != end; ++it idiom defunct. –
Selenite for_each algorithm. It is equivalent to the range-based for syntax in C++11. And he points out how much it's better than that, since you can continue, break, return, and things you can't with lambdas. The range-based for is not "a loop"; it's specifically a loop over all the elements of a range. –
Longdistance for_each algorithm over the range based for loop is that you can't break or return. That is, when you see for_each you know immediately without looking at the body that there's no such trickiness. –
Britanybritches break. Luckily for me, I have syntax coloring, so I can pretty easily identify early loop exits. –
Mandelbaum std::for_each(v.begin(), v.end(), [](int &i) { ++i; }); with for (auto &i : v) { ++i; }. I accept that flexibility is double-edged (goto is very flexible, that's the problem). I don't think that the constraint of not being able to use break in the for_each version compensates for the extra verbosity it demands -- users of for_each here are IMO sacrificing actual readability and convenience for a kind of theoretical notion that the for_each is in principle clearer and conceptually simpler. In practice it isn't clearer or simpler. –
Mandelbaum for_each is relatively heavy, but I don't think the tradeoffs will always come out in favor of range based for. Though to be fair I'm one of those people that used algorithms with bind1st, bind2nd, and standard functors before we had lambda and bind, so what I find more readable isn't necessarily the same as what others find readable (e.g. for a loop that increments every element in an array I think transform rather than for_each). –
Britanybritches it = c.begin(), const end = c.end(); is not valid, const applies to all declarations. –
Reciprocate You'll need to implement custom versions of swap less often. In C++03, an efficient non-throwing swap is often necessary to avoid costly and throwing copies, and since std::swap uses two copies, swap often has to be customized. In C++, std::swap uses move, and so the focus shifts on implementing efficient and non-throwing move constructors and move assignment operators. Since for these the default is often just fine, this will be much less work than in C++03.
Generally it's hard to predict which idioms will be used since they are created through experience. We can expect an "Effective C++11" maybe next year, and a "C++11 Coding Standards" only in three years because the necessary experience isn't there yet.
I do not know the name for it, but C++03 code often used the following construct as a replacement for missing move assignment:
std::map<Big, Bigger> createBigMap(); // returns by value
void example ()
{
std::map<Big, Bigger> map;
// ... some code using map
createBigMap().swap(map); // cheap swap
}
This avoided any copying due to copy elision combined with the swap above.
map anyway. The technique you show is useful if map already exists, rather than just being constructed. The example would be better without the "cheap default constructor" comment and with "// ..." between that construction and the swap –
Chardin When I noticed that a compiler using the C++11 standard no longer faults the following code:
std::vector<std::vector<int>> a;
for supposedly containing operator>>, I began to dance. In the earlier versions one would have to do
std::vector<std::vector<int> > a;
To make matters worse, if you ever had to debug this, you know how horrendous are the error messages that come out of this.
I, however, do not know if this was "obvious" to you.
Return by value is no longer a problem. With move semantics and/or return value optimization (compiler dependent) coding functions are more natural with no overhead or cost (most of the time).
© 2022 - 2024 — McMap. All rights reserved.
auto_ptris deprecated, too. – Calpacconst_ptr,make_shared(and themake_uniquethat should have been in the standard), and rvalue reference changed the "right" way to do things in a big way. – Trimurticonstvalues is no longer encouraged in C++11? – Reaganconstvalue cannot be modified, and thus cannot be moved from. – Diuresis