6 ms·

C++ Tips of the Week

212 points by fauigerzigerk 9y ago

signa11 9y ago
something similar was initiated by herb-sutter as well in his 'guru of the week' (gotw) columns. which then became books in their own right aka 'exceptional c++' series. are these tips more 'modernish' ?
- fauigerzigerk 9y ago
  Both series have been created over many years, so I'm not sure which one is more modern. Herb Sutter says that all GotW articles are being revised to reflect changes in C++14.
- SwellJoe 9y ago
  Tip #1 covers a feature found in C++17, so I'd say yes.
  - jzwinck 9y ago
    Tip #1 appears on the surface to be about C++17's std::string_view, but many shops had something similar to string_view for a decade or more before C++ made it official. The tips are not presented in their original form; edits have been made (as per the linked page). I think Google had something like string_view by 2009 at the latest, using C++03 compilers.
    - humanrebar 9y ago
      Links to illustrate: https://github.com/boostorg/utility/blob/develop/include/boost/utility/string_ref.hpp https://github.com/boostorg/utility/blob/develop/include/boo... This proposal references Google and LLVM implementations: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3442.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n344... Looks like the LLVM implementation goes back to at least 2009: https://github.com/llvm-mirror/llvm/blob/master/include/llvm/ADT/StringRef.h https://github.com/llvm-mirror/llvm/blob/master/include/llvm...
    - dogruck 9y ago
      Yeah, discussing the origins of string_view is like talking about who invented base-two numbering. :-)
      - humanrebar 9y ago
        Yes. It is a small step from the well-worn convention to pass each char* around with its length.
        signa11 9y ago
        > Yes. It is a small step from the well-worn convention to pass each char* around with its length. kind of surprising to note that implicit 'string_view' conversions are now regarded as a good thing? on a side note, the language is _complicated_, and shows no signs of stopping ! 3 articles on move/copy ctor's and only one that applies to programming in general.
    - fooker 9y ago
      >I think Google had something like string_view by 2009 at the latest, using C++03 compilers. Yeah, StringPiece http://google.github.io/google-api-cpp-client/latest/doxygen/stringpiece_8h_source.html http://google.github.io/google-api-cpp-client/latest/doxygen...
    - apaprocki 9y ago
      Here's Bloomberg's version: https://bloomberg.github.io/bde/group__bslstl__stringref.html https://bloomberg.github.io/bde/group__bslstl__stringref.htm...
    - TwoBit 9y ago
      EASTL had it at least as early as 2005.
    - ksherlock 9y ago
      And they also claim string_views can be constructed from a std::string. That's true of their implementation and it's true of the TS string_view but it was removed from the c++17 string_view.
- stochastic_monk 9y ago
  Herb Sutter's recent tips are more modern (and the backlog is being updated). Scott Meyers' Effective Modern C++ is a great successor to his Effective C++ book which spawned the whole "Effective *" snowclone books and covers C++14, though not 17, of course. Actually, this blog post's content looks like a watered-down version of a tip from either or both of the above authors, though I'm too lazy to chase down a verification.
weeklyrust 9y ago
No amount of 'tips' can save this language now. C++ never had a clear goal. The features of C++ were added almost at random. Stroustrup's original idea was essentially "C is cool and OOP is cool so let's bolt OOP onto C". Retrospectively, OOP was massively overhyped and is the wrong tool for the job for most of the people most of the time. Half of the GoF design patterns just emulate idioms from functional programming. Real OOP languages like Smalltalk and IO express many useful things that C++ cannot. The feature that C needed most was perhaps parametric polymorphism (aka generics in Java and C#, first seen in ML in the late 1970s) but instead of that C++ got templates that weren't designed to solve any particular problem but rather to kind of solve several completely unrelated problems (e.g. generics and metaprogramming). Someone actually discovered by accident that C++ templates are Turing complete and they wrote and published a program that computed prime numbers at compile time. Wow. A remarkable observation that led to decades of template abuse where people used templates to solve problems much better solved by other pre-existing solutions such Lisp macros and ML polymorphism. Worse, this abuse led to even more language features being piled on top, like template partial specialization. The massive incidental complexity in C++ made it almost impossible to write a working compiler. For example, it remains extremely difficult to write a parser for the C++ language. The syntax also has horrible aspects like List<Set<int>> being interpreted as logical shift right. None of the original C++ compilers were reliable. Only after two decades did we start to see solid C++ compilers (by which time C++ was in decline in industry due to Java and C#). C++ is said to be fast but the reality is that C++ is essentially only fast when you write C-like code and even then it is only fast for certain kinds of programs. Due to the "you don't pay for what you don't use" attitude, C++ is generally inefficient. RAII injects lots of unnecessary function calls at the end of scope, sometimes even expensive virtual calls. These calls often require data that would otherwise be dead so the data are kept alive, increasing register pressure and spilling and decreasing performance. The C++ exception mechanism is very inefficient (~6x slower than OCaml) because it unwinds the stack frame by frame calling destructors rather than long jumping. Allocation with new and delete is slow compared to a modern garbage collector so people are encouraged to use STL collections but these pre-allocate huge blocks of memory in comparison so you've lost the memory-efficiency of C and then you are advised to write your own STL allocator which is no better than using C in the first place. One of the main long-standing advantages of C over modern languages is the unpredictable latency incurred by garbage collectors. C++ offers the worst of both worlds by not having a garbage collector (making it impossible to leverage useful concepts like purely functional data structures properly) but it encourages all destructors to avalanche so you get unbounded pause times (worse than any production GC). Although templates are abused for metaprogramming they are very poor at it and C++ has no real support for metaprogramming. For example, you cannot write an efficient portable regular expression library in C++ because there is no way to do run-time code generation and compilation as you can in Java, C# and languages dating back to Lisp (1960). So while Java and C# have had regular expressions in their standard libraries for well over 10 years, C++ only just got them and they are slow. C++ is so complicated that even world experts make rookie mistakes with it. Herb Sutter works for Microsoft and sits on the C++ standards committee where he influences the future of C++. In a lecture he gave his favorite 10-line C++ program, a thread-safe object cache. My personal feeling is that the new Rust programming language is what C++ should have been. It has useful known features like generics, discriminated unions and pattern matching and useful new features like memory safety without garbage collection.
branchless 9y ago
I've failed the first test: how do I get a list of all "tips"?
- ma2rten 9y ago
  I think they only made those 4 public for now.
  - branchless 9y ago
    shame, was going to binge read them
unkown-unknowns 9y ago
Seems that only four of the tips are available?
- bpicolo 9y ago
  They're doing one a week, starting 4 weeks ago.
  - dogruck 9y ago
    They should reindex their archive of tips. I was baffled by the jump from tip 1 to 55 to 77. Edit: the indexing is explained in a note on the site.
    - cbcoutinho 9y ago
      The index is related to when the tips were published internally at Google, and are not re-indexed for the sake of those who have already seen them
    - steev 9y ago
      This is specifically addressed in the article at the bottom as a note.
    - wingerlang 9y ago
      If you look at the paragraph above them, last in the article they explain why it is.
  - misnome 9y ago
    On average it seems, because it took a months wait for three to be released at once. Hopefully whatever stopped the project has been resolved and they’ll be consistent now.
ThePhysicist 9y ago
In a similar vein, we published a „little book of Python anti patterns“ a while back, maybe some people find it useful: https://docs.quantifiedcode.com/python-anti-patterns https://docs.quantifiedcode.com/python-anti-patterns
ndh2 9y ago
> We’ve decided to expose most of these tips to the Abseil development community, and the C++ community at large. Over the coming months, we’ll be posting new tips as we review and refine them for publication. Not all the entries we’ve written are relevant to the outside world; some were specific to our internal tools and abstractions, and some have become obsolete as the language has changed.
- xarball 9y ago
  I followed a few links to Abseil: > Consisting of the foundational C++ and Python code at Google, Abseil includes libraries that will grow to underpin other Google-backed open source projects like gRPC, Protobuf and TensorFlow. This library already seems like it is suffering from scope-creep. Tensorflow, gRPC, and Protobuf are hardly related to improving the C++ standard. Why are these even in the same library at all?
  - deleted 9y ago
    [deleted]
  - ndh2 9y ago
    They're not. They will be using Abseil.
  - misnome 9y ago
    “Underpin” e.g. those libraries will use Abseil as a common base.
  - perfmode 9y ago
    Google needs to open source its core C++ libraries if it is going to open source the projects that depend on the core libraries.
HellDunkel 9y ago
Here is my personal advice: whatever code you write, make sure you can grab it and run leaving no trace behind.
deepakkarki 9y ago
For those interested in such insightful tech reads, I run https://discoverdev.io https://discoverdev.io - a daily curated list of top 8 to 10 engineering blog posts! Published every weekday!
hartcw 9y ago
Naming of the title reminds me of the best C book I've read, "Expert C Programming: Deep C Secret" by Peter Van Der Linden. https://g.co/kgs/Gyvg69 https://g.co/kgs/Gyvg69
mbrubeck 9y ago
Use string_view, but beware of use-after-free bugs like https://github.com/isocpp/CppCoreGuidelines/issues/1038 https://github.com/isocpp/CppCoreGuidelines/issues/1038
- inetknght 9y ago
  Think of string_view as a non-owning pointer to a known-size array. If the array is moved or destroyed, then string_view is left dangling... just like a pointer.

212 points by fauigerzigerk 9y ago

something similar was initiated by herb-sutter as well in his 'guru of the week' (gotw) columns. which then became books in their own right aka 'exceptional c++' series. are these tips more 'modernish' ?

fauigerzigerk 9y ago
Both series have been created over many years, so I'm not sure which one is more modern. Herb Sutter says that all GotW articles are being revised to reflect changes in C++14.
SwellJoe 9y ago
Tip #1 covers a feature found in C++17, so I'd say yes.
- jzwinck 9y ago
  Tip #1 appears on the surface to be about C++17's std::string_view, but many shops had something similar to string_view for a decade or more before C++ made it official. The tips are not presented in their original form; edits have been made (as per the linked page). I think Google had something like string_view by 2009 at the latest, using C++03 compilers.
  - humanrebar 9y ago
    Links to illustrate: https://github.com/boostorg/utility/blob/develop/include/boost/utility/string_ref.hpp https://github.com/boostorg/utility/blob/develop/include/boo... This proposal references Google and LLVM implementations: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3442.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n344... Looks like the LLVM implementation goes back to at least 2009: https://github.com/llvm-mirror/llvm/blob/master/include/llvm/ADT/StringRef.h https://github.com/llvm-mirror/llvm/blob/master/include/llvm...
  - dogruck 9y ago
    Yeah, discussing the origins of string_view is like talking about who invented base-two numbering. :-)
    - humanrebar 9y ago
      Yes. It is a small step from the well-worn convention to pass each char* around with its length.
      - signa11 9y ago
        > Yes. It is a small step from the well-worn convention to pass each char* around with its length. kind of surprising to note that implicit 'string_view' conversions are now regarded as a good thing? on a side note, the language is _complicated_, and shows no signs of stopping ! 3 articles on move/copy ctor's and only one that applies to programming in general.
  - fooker 9y ago
    >I think Google had something like string_view by 2009 at the latest, using C++03 compilers. Yeah, StringPiece http://google.github.io/google-api-cpp-client/latest/doxygen/stringpiece_8h_source.html http://google.github.io/google-api-cpp-client/latest/doxygen...
  - apaprocki 9y ago
    Here's Bloomberg's version: https://bloomberg.github.io/bde/group__bslstl__stringref.html https://bloomberg.github.io/bde/group__bslstl__stringref.htm...
  - TwoBit 9y ago
    EASTL had it at least as early as 2005.
  - ksherlock 9y ago
    And they also claim string_views can be constructed from a std::string. That's true of their implementation and it's true of the TS string_view but it was removed from the c++17 string_view.
stochastic_monk 9y ago
Herb Sutter's recent tips are more modern (and the backlog is being updated). Scott Meyers' Effective Modern C++ is a great successor to his Effective C++ book which spawned the whole "Effective *" snowclone books and covers C++14, though not 17, of course. Actually, this blog post's content looks like a watered-down version of a tip from either or both of the above authors, though I'm too lazy to chase down a verification.

weeklyrust 9y ago

No amount of 'tips' can save this language now. C++ never had a clear goal. The features of C++ were added almost at random. Stroustrup's original idea was essentially "C is cool and OOP is cool so let's bolt OOP onto C". Retrospectively, OOP was massively overhyped and is the wrong tool for the job for most of the people most of the time. Half of the GoF design patterns just emulate idioms from functional programming. Real OOP languages like Smalltalk and IO express many useful things that C++ cannot. The feature that C needed most was perhaps parametric polymorphism (aka generics in Java and C#, first seen in ML in the late 1970s) but instead of that C++ got templates that weren't designed to solve any particular problem but rather to kind of solve several completely unrelated problems (e.g. generics and metaprogramming). Someone actually discovered by accident that C++ templates are Turing complete and they wrote and published a program that computed prime numbers at compile time. Wow. A remarkable observation that led to decades of template abuse where people used templates to solve problems much better solved by other pre-existing solutions such Lisp macros and ML polymorphism. Worse, this abuse led to even more language features being piled on top, like template partial specialization. The massive incidental complexity in C++ made it almost impossible to write a working compiler. For example, it remains extremely difficult to write a parser for the C++ language. The syntax also has horrible aspects like List<Set<int>> being interpreted as logical shift right. None of the original C++ compilers were reliable. Only after two decades did we start to see solid C++ compilers (by which time C++ was in decline in industry due to Java and C#). C++ is said to be fast but the reality is that C++ is essentially only fast when you write C-like code and even then it is only fast for certain kinds of programs. Due to the "you don't pay for what you don't use" attitude, C++ is generally inefficient. RAII injects lots of unnecessary function calls at the end of scope, sometimes even expensive virtual calls. These calls often require data that would otherwise be dead so the data are kept alive, increasing register pressure and spilling and decreasing performance. The C++ exception mechanism is very inefficient (~6x slower than OCaml) because it unwinds the stack frame by frame calling destructors rather than long jumping. Allocation with new and delete is slow compared to a modern garbage collector so people are encouraged to use STL collections but these pre-allocate huge blocks of memory in comparison so you've lost the memory-efficiency of C and then you are advised to write your own STL allocator which is no better than using C in the first place. One of the main long-standing advantages of C over modern languages is the unpredictable latency incurred by garbage collectors. C++ offers the worst of both worlds by not having a garbage collector (making it impossible to leverage useful concepts like purely functional data structures properly) but it encourages all destructors to avalanche so you get unbounded pause times (worse than any production GC). Although templates are abused for metaprogramming they are very poor at it and C++ has no real support for metaprogramming. For example, you cannot write an efficient portable regular expression library in C++ because there is no way to do run-time code generation and compilation as you can in Java, C# and languages dating back to Lisp (1960). So while Java and C# have had regular expressions in their standard libraries for well over 10 years, C++ only just got them and they are slow. C++ is so complicated that even world experts make rookie mistakes with it. Herb Sutter works for Microsoft and sits on the C++ standards committee where he influences the future of C++. In a lecture he gave his favorite 10-line C++ program, a thread-safe object cache. My personal feeling is that the new Rust programming language is what C++ should have been. It has useful known features like generics, discriminated unions and pattern matching and useful new features like memory safety without garbage collection.

branchless 9y ago

I've failed the first test: how do I get a list of all "tips"?

ma2rten 9y ago
I think they only made those 4 public for now.
- branchless 9y ago
  shame, was going to binge read them

unkown-unknowns 9y ago

Seems that only four of the tips are available?

bpicolo 9y ago
They're doing one a week, starting 4 weeks ago.
- dogruck 9y ago
  They should reindex their archive of tips. I was baffled by the jump from tip 1 to 55 to 77. Edit: the indexing is explained in a note on the site.
  - cbcoutinho 9y ago
    The index is related to when the tips were published internally at Google, and are not re-indexed for the sake of those who have already seen them
  - steev 9y ago
    This is specifically addressed in the article at the bottom as a note.
  - wingerlang 9y ago
    If you look at the paragraph above them, last in the article they explain why it is.
- misnome 9y ago
  On average it seems, because it took a months wait for three to be released at once. Hopefully whatever stopped the project has been resolved and they’ll be consistent now.

ThePhysicist 9y ago

In a similar vein, we published a „little book of Python anti patterns“ a while back, maybe some people find it useful: https://docs.quantifiedcode.com/python-anti-patterns https://docs.quantifiedcode.com/python-anti-patterns

ndh2 9y ago

> We’ve decided to expose most of these tips to the Abseil development community, and the C++ community at large. Over the coming months, we’ll be posting new tips as we review and refine them for publication. Not all the entries we’ve written are relevant to the outside world; some were specific to our internal tools and abstractions, and some have become obsolete as the language has changed.

xarball 9y ago
I followed a few links to Abseil: > Consisting of the foundational C++ and Python code at Google, Abseil includes libraries that will grow to underpin other Google-backed open source projects like gRPC, Protobuf and TensorFlow. This library already seems like it is suffering from scope-creep. Tensorflow, gRPC, and Protobuf are hardly related to improving the C++ standard. Why are these even in the same library at all?
- deleted 9y ago
  [deleted]
- ndh2 9y ago
  They're not. They will be using Abseil.
- misnome 9y ago
  “Underpin” e.g. those libraries will use Abseil as a common base.
- perfmode 9y ago
  Google needs to open source its core C++ libraries if it is going to open source the projects that depend on the core libraries.

HellDunkel 9y ago

Here is my personal advice: whatever code you write, make sure you can grab it and run leaving no trace behind.

deepakkarki 9y ago

For those interested in such insightful tech reads, I run https://discoverdev.io https://discoverdev.io - a daily curated list of top 8 to 10 engineering blog posts! Published every weekday!

hartcw 9y ago

Naming of the title reminds me of the best C book I've read, "Expert C Programming: Deep C Secret" by Peter Van Der Linden. https://g.co/kgs/Gyvg69 https://g.co/kgs/Gyvg69

mbrubeck 9y ago

Use string_view, but beware of use-after-free bugs like https://github.com/isocpp/CppCoreGuidelines/issues/1038 https://github.com/isocpp/CppCoreGuidelines/issues/1038

inetknght 9y ago
Think of string_view as a non-owning pointer to a known-size array. If the array is moved or destroyed, then string_view is left dangling... just like a pointer.