{"id":1031,"date":"2015-02-20T22:52:05","date_gmt":"2015-02-21T06:52:05","guid":{"rendered":"http:\/\/www.elbeno.com\/blog\/?p=1031"},"modified":"2015-06-30T21:16:32","modified_gmt":"2015-07-01T04:16:32","slug":"c11-no-brainer-features","status":"publish","type":"post","link":"https:\/\/www.elbeno.com\/blog\/?p=1031","title":{"rendered":"Adopting C++11: no-brainer features"},"content":{"rendered":"

C++11\/14 is a significant change from C++98\/03, and features like move semantics take a while to get used to. Also, people tend to be quite conservative about adopting new features (especially if they look unfamiliar). It took us in the games industry a while to move to C++ from C. But here are what I consider the no-brainer, programming-in-the-small things to adopt. Extra safety and expressiveness with zero runtime impact and pretty much no potential for misuse (never say never, but you’d really have to go out of your way).<\/p>\n

1.<\/strong> using<\/code> instead of typedef<\/code><\/p>\n

Not only is it a whole two characters fewer to type, it’s easier to read in the common function pointer case, and you can use it for template aliases, which often saves a lot more verbosity in the rest of the code. No more typename<\/code> everywhere! Compare:<\/p>\n

\r\n\/\/ old and busted: typedef\r\ntemplate \r\nstruct Foo\r\n{\r\n  \/\/ I can't typedef Foo::type \r\n  \/\/ and I have to use typename everywhere\r\n  typedef T type;\r\n};\r\n\r\n\/\/ Typical usage: a function pointer\r\ntypedef void (*funcptr)(int);\r\n<\/pre>\n
\r\n\/\/ new hotness: using\r\ntemplate \r\nstruct Foo\r\n{\r\n  using type = T;\r\n};\r\n\r\n\/\/ This pattern is used a lot in C++14 STL\r\ntemplate \r\nusing foo_t = typename Foo::type;\r\n\r\n\/\/ Function pointer is easier to read\r\nusing funcptr = void (*)(int);\r\n<\/pre>\n
2.<\/strong> static_assert<\/code><\/p>\n
Compile-time asserts; what’s not to like? Odds are you have a homegrown C++98 TMP version of this somewhere; now it’s part of the language. Extra safety for zero runtime cost.<\/p>\n
3.<\/strong> nullptr<\/code><\/p>\n
Again, extra safety for zero cost. Ditch your zeros and NULLs, and you can safely have functions overloaded on pointer and integral types.<\/p>\n
4.<\/strong> scoped enum<\/code>s (enum class<\/code>)<\/p>\n
The compiler can help prevent accidental confusion between types, and the enum<\/code> values don’t leak any more. Hurrah! (It’s like Haskell’s newtype<\/code> for integers!)<\/p>\n
5.<\/strong> forward declarations of enum<\/code>s, underlying type for enum<\/code>s<\/p>\n
This works on (new) scoped and (old) unscoped enum<\/code>s alike. You don’t have to put in fake bit-width values to force the size of an enum<\/code> any more, and you can hide the values separately from the declaration, so you don’t need to recompile everything when you add a value.<\/p>\n
6.<\/strong> override<\/code><\/p>\n
When (for example) the class you’re deriving from changes upstream, and now you’re accidentally not overriding a member function you thought you were… you’d really like to know that. With override<\/code>, a bug that might take you a couple of hours to track down becomes a trivial-to-fix compile error. (Often mentioned in the same breath as override<\/code> is final<\/code>, and it’s fine, but much less usefully applicable.)<\/p>\n
Now, there are also a couple of things to stop using.<\/p>\n
1.<\/strong> rand()<\/code><\/p>\n
Stop using rand()<\/code>. Really, it’s bad. Deep down, we always knew it was “bad” but maybe we convinced ourselves it was OK for “small”\/”quick-and-dirty” tasks. It isn’t. And now, it’s not any easier or faster than just doing the Right Thing with <random><\/code>. STL explains it all in rand() considered harmful<\/a>.<\/p>\n
2.<\/strong> bind<\/code><\/p>\n
Lambdas supersede bind<\/code> in every way. They’re more straightforward to write, easier to read, as powerful and at least as efficient if not more so, and just… you know, not so weird<\/em>. And if you think lambdas take some getting used to, well, I don’t think I ever got used to bind<\/code>…<\/p>\n","protected":false},"excerpt":{"rendered":"
C++11\/14 is a significant change from C++98\/03, and features like move semantics take a while to get used to. Also, people tend to be quite conservative about adopting new features (especially if they look unfamiliar). It took us in the games industry a while to move to C++ from C….<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22,8],"tags":[],"class_list":["post-1031","post","type-post","status-publish","format-standard","hentry","category-cpp","category-programming"],"_links":{"self":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1031","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1031"}],"version-history":[{"count":18,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1031\/revisions"}],"predecessor-version":[{"id":1049,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1031\/revisions\/1049"}],"wp:attachment":[{"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1031"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1031"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.elbeno.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1031"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}