4 ms·

You're in for a wild ride. C++ takes forever to learn (basically, it never ends) and people have VERY different senses of what "clean" C++ code is like. And fo

You're in for a wild ride. C++ takes forever to learn (basically, it never ends) and people have VERY different senses of what "clean" C++ code is like. And for that matter, even the same person might write in different styles depending on the situation. And the same exact style might be terrible for one situation but awesome for another. With all that said, one "good" kind of codebase to at least know (even if you can't emulate it) is the kind of codebase that is modeled after the C++ standard library. Some Boost libraries (not all!) are great examples of this. Probably the best example I can think of off the top of my head is Boost.Container: https://www.boost.org/doc/libs/1_74_0/boost/container/vector.hpp https://www.boost.org/doc/libs/1_74_0/boost/container/vector... Note that this does not mean you should write code like this for your applications, though. Boost is heavyweight with the templates/headers/macros and these classes are meant to be extremely generic. Your application-level code does not necessarily need to meet the same types of constraints, and it's just not worth the effort in most cases (as well as being slower to compile). But if you can write this kind of code when it's warranted, it ends up being very high-quality. (Some parts of this involve a lot of difficult work, like paying attention to exception-safety, that is often unnecessary. Other parts are quite simple and well worth picking up, e.g. liberal use of typedefs. And everything else in between.) A more typical example of a codebase might be some of wxWidgets, e.g.: https://github.com/wxWidgets/wxWidgets/blob/v3.1.4/src/generic/listctrl.cpp https://github.com/wxWidgets/wxWidgets/blob/v3.1.4/src/gener... It's not in the style of the standard library (so you won't find it to be as generic, exception-safe, etc.) but it's pretty decent.

jstimpfle 6y ago
> Probably the best example I can think of off the top of my head is Boost.Container: > https://www.boost.org/doc/libs/1_74_0/boost/container/vector https://www.boost.org/doc/libs/1_74_0/boost/container/vector... Which I find absolutely hilarious. Thousands of lines of boilerplate for something as simple as an dynamically resizable array. Only for the _header_ which has to be included at each location that uses a vector either directly or indirectly. These are the kinds of things that prevent me from touching C++.
- fsloth 6y ago
  "These are the kinds of things that prevent me from touching C++" Please don't let boost stop you. At my team we avoid boost like the plague and prefer terse and pragmatic code. IMO C++ is best approached like C but with convenient data structures in the standard library - and tons of patterns that _may_ be taken into use if they simplify the code. That said, unless you are working in a specific setting where C++ is obviously the best tool, you probably should not use C++. Even at best of times C++ is complex and unproductive. But it offers an unbeatable combination of ecosystem maturity, robustness, close to the metal performance and high level concepts to fit few slots better than anything else.
  - ncmncm 6y ago
    If you are unproductive when coding C++, you are Doing It Wrong. Good C++ code flows like water. If you are finding it complex, you have gone down a side alley, and need to get back to the wide, sunny boulevard. I frequently sit down and write 2000 lines of C++ code, and when it compiles, it works. Aim for that.
    - fsloth 6y ago
      My 2000 lines of C++ work fine just as well. C++ is unproductive when compared to other languages. C++ can be found to be the best language for a specific class of problems. But. Those 2000 lines of C++? If that code had been python or F# or even C# and the problem had been 'generic' enough it would likely have less lines of code and be done faster. If that 2k lines happened to implement some numerics stuff with hard performance requirements then C++ might come up on top. But my complaint overall is not about a short 2k line program. It's about the whole program lifetime and software complexity of a complex system. For non-trivial programs C++ opens a whole can of worms concerning compatibility, deployment, locales, memory handling, weird bugs due to sometimes obscure lifetimes, integer sizes on different plarforms... etc etc. And the C++ spec is infinite for most mortals.
- huhtenberg 6y ago
  Indeed. To each his own. I've been using C++ as a daily workhorse since the early 90s and Boost and its standardized derivatives is easily the worst thing that ever happened to the language. It may all make logical sense, but the end result looks, basically, like butt. It is not a refined, thoughtfully evolved language that is a pleasure to use. It has so many features bolted on at so many different angles that it has no distinct shape anymore. Design by committee at its finest.
lentil_soup 6y ago
> Other parts are quite simple and well worth picking up, e.g. liberal use of typedefs honest question, why do you think liberal use of typedefs is a good habit to pick up?
- mehrdadn 6y ago
  Lots of reasons. It's just something I've learned based on experience. They're essentially free abstractions that confine a source of truth (the type of a variable) to a single location. They codify the abstractions as well. They make it easier to understand the semantic purpose of each type and can make meaningful distinctions when concrete types are the same (e.g. std::vector<size_t> is quite unilluminating compared to, say, 'NameIndices' and 'ValueIndices'). They make it very easy to change types down the road (as the concrete type is now declared in a single location). They give you control over the type inference procedure. And they give you the majority of the benefits of 'auto' without the same pitfalls. That said, I'm not suggesting you use them indiscriminately. 'this_type' and 'value_type' are often useful; 'difference_type' and 'size_type' generally won't gain you anything...
MaxBarraclough 6y ago
> C++ takes forever to learn (basically, it never ends) It's not just that it has a huge and growing feature-set, it also has an outsize wealth of dark corners. As a slight silver lining, there's an excellent community on StackOverflow where these quirks are explained well. You can spend hours just reading about initialization in C++. I have, and I can only recall a small fraction of it (but I rarely use C++). It's nightmarish in ways you'd never imagine. [0][1][2] [0] https://stackoverflow.com/a/54350350/ https://stackoverflow.com/a/54350350/ [1] https://stackoverflow.com/a/620402/ https://stackoverflow.com/a/620402/ [2] https://news.ycombinator.com/item?id=18832311 https://news.ycombinator.com/item?id=18832311

jstimpfle 6y ago

> Probably the best example I can think of off the top of my head is Boost.Container: > https://www.boost.org/doc/libs/1_74_0/boost/container/vector https://www.boost.org/doc/libs/1_74_0/boost/container/vector... Which I find absolutely hilarious. Thousands of lines of boilerplate for something as simple as an dynamically resizable array. Only for the _header_ which has to be included at each location that uses a vector either directly or indirectly. These are the kinds of things that prevent me from touching C++.

fsloth 6y ago
"These are the kinds of things that prevent me from touching C++" Please don't let boost stop you. At my team we avoid boost like the plague and prefer terse and pragmatic code. IMO C++ is best approached like C but with convenient data structures in the standard library - and tons of patterns that _may_ be taken into use if they simplify the code. That said, unless you are working in a specific setting where C++ is obviously the best tool, you probably should not use C++. Even at best of times C++ is complex and unproductive. But it offers an unbeatable combination of ecosystem maturity, robustness, close to the metal performance and high level concepts to fit few slots better than anything else.
- ncmncm 6y ago
  If you are unproductive when coding C++, you are Doing It Wrong. Good C++ code flows like water. If you are finding it complex, you have gone down a side alley, and need to get back to the wide, sunny boulevard. I frequently sit down and write 2000 lines of C++ code, and when it compiles, it works. Aim for that.
  - fsloth 6y ago
    My 2000 lines of C++ work fine just as well. C++ is unproductive when compared to other languages. C++ can be found to be the best language for a specific class of problems. But. Those 2000 lines of C++? If that code had been python or F# or even C# and the problem had been 'generic' enough it would likely have less lines of code and be done faster. If that 2k lines happened to implement some numerics stuff with hard performance requirements then C++ might come up on top. But my complaint overall is not about a short 2k line program. It's about the whole program lifetime and software complexity of a complex system. For non-trivial programs C++ opens a whole can of worms concerning compatibility, deployment, locales, memory handling, weird bugs due to sometimes obscure lifetimes, integer sizes on different plarforms... etc etc. And the C++ spec is infinite for most mortals.
huhtenberg 6y ago
Indeed. To each his own. I've been using C++ as a daily workhorse since the early 90s and Boost and its standardized derivatives is easily the worst thing that ever happened to the language. It may all make logical sense, but the end result looks, basically, like butt. It is not a refined, thoughtfully evolved language that is a pleasure to use. It has so many features bolted on at so many different angles that it has no distinct shape anymore. Design by committee at its finest.

lentil_soup 6y ago

> Other parts are quite simple and well worth picking up, e.g. liberal use of typedefs honest question, why do you think liberal use of typedefs is a good habit to pick up?

mehrdadn 6y ago
Lots of reasons. It's just something I've learned based on experience. They're essentially free abstractions that confine a source of truth (the type of a variable) to a single location. They codify the abstractions as well. They make it easier to understand the semantic purpose of each type and can make meaningful distinctions when concrete types are the same (e.g. std::vector<size_t> is quite unilluminating compared to, say, 'NameIndices' and 'ValueIndices'). They make it very easy to change types down the road (as the concrete type is now declared in a single location). They give you control over the type inference procedure. And they give you the majority of the benefits of 'auto' without the same pitfalls. That said, I'm not suggesting you use them indiscriminately. 'this_type' and 'value_type' are often useful; 'difference_type' and 'size_type' generally won't gain you anything...

MaxBarraclough 6y ago

> C++ takes forever to learn (basically, it never ends) It's not just that it has a huge and growing feature-set, it also has an outsize wealth of dark corners. As a slight silver lining, there's an excellent community on StackOverflow where these quirks are explained well. You can spend hours just reading about initialization in C++. I have, and I can only recall a small fraction of it (but I rarely use C++). It's nightmarish in ways you'd never imagine. [0][1][2] [0] https://stackoverflow.com/a/54350350/ https://stackoverflow.com/a/54350350/ [1] https://stackoverflow.com/a/620402/ https://stackoverflow.com/a/620402/ [2] https://news.ycombinator.com/item?id=18832311 https://news.ycombinator.com/item?id=18832311