6 ms·

I used to teach C++ courses as a consultant. This kind of thing was part of the gospel I was trying to spread. Educate my follow software developers on the meri

• rambojazz 4y ago
  I loved C++, for a while. I chose to leave its grammar's complexity behind too.
• pjmlp 4y ago
  C++ is one of my favourite languages, yet I second the feeling, sometimes preaching good practices feels like fighting windmills, so I spend most of my time on languages where I don't need to discuss about the virtues of bounds checking or exceptions every single day.
• billti 4y ago
  When I was "seriously" using C++ I created myself a bunch of flashcards (using the Quizlet app) to regularly test myself (spaced repetition) on various C++ idioms and rules; such as when to implement which copy/assignment/move constructors and the correct patterns, how to use std::forward correctly, the footguns in various types of casting or initialization, etc. I recently had cause to start using C++ again and went over the cards after about a year break. It was depressing how few I could answer correctly. C++ is great if you're great with it, but that takes a __lot__ of effort, and it can be a minefield otherwise.
  • 0xfaded 4y ago
    I have a notebook I filled with Q&As for every point in The CPP Programming Language that surprised me. It's about 40 pages I occasionally read through, though I've been meaning to convert it to spaced repetition.
• beached_whale 4y ago
  Less is more is what most code should strive for these days. The copy/move ctors and assignment ops should be rare and are often a single resp violation otherwise. Code like optional or smart pointers sure, they are fair game for that, but business logic generally shouldnt bother.
• jack_h 4y ago
  I've been using C++ for around 20 years now. I've spent a lot of time learning the language, although I don't know any of C++20 yet. The issue with C++ is that the 'proper' way to do something almost always requires an encyclopedic knowledge of the language; any other solution you come up with will likely be wrong or at the very least suboptimal for esoteric reasons. It's not that people aren't smart enough, it's that there's not enough time to really learn the language. I know I've sacrificed sleep and social life just doing deep dives into the language to really understand it. The reason I don't know C++20 yet is because I'm not willing to make those personal sacrifices anymore, and even if we could use C++20 where I work we don't have infinite time to learn it before being productive.
  • gabereiser 4y ago
    This. That encyclopedic knowledge of gotcha’s and work arounds and such is why people hate C++ so much. It’s far beyond tolerable. If you were to restrict everything to just c++20 (force shard_ptr, etc) it would still be something only battle hardened adventurers would pursue. Languages like Go and Nim and the all mighty Rust try to take away complexity for a bit of convention and provide safety for us mortals that just want to get an idea across. For those that are weathering the storm in C++, I commend you, but you’re going to need therapy. (joke but the effects of stress are real).
    • synergy20 4y ago
      I somehow feel Rust is even more complex than C++ For C++ I settle down with c++17|c++20 and they're still complex, but not that bad though. Go might be simpler but C++ can do whatever Go does and I tried to master both, it did not work, so I had to pick one and that one has to be c++ for my use cases.
      • gabereiser 4y ago
        Getting around Rust’s syntax is pretty much the whole battle.
        • 4y ago
• nocman 4y ago
  My opinion is similar to others in this thread. The complexity you are required to manage in order to push the limits of C++ makes doing so not worth it. There are far too many ways it can bite you, and the benefits you gain by moving beyond a small subset of C++'s capabilities were not worth the hassle for me. I really wanted them to be worth it, and spent years trying to make it worth it. I guess in the long run it was worth the time spent, because it caused me to explore other possibilities that I might not otherwise have considered (in particular, Lisp and Scheme-like languages, which I doubt I would have otherwise given a second look -- they were just "weird languages that we spent a couple of weeks looking at in college - and oh, yeah what's up with all those freaking parentheses?").
  • josefx 4y ago
    > The complexity you are required to manage in order to push the limits of C++ makes doing so not worth it. Sometimes the point is just having it possible. Sometimes I need to get that last bit of performance out of some code. > (in particular, Lisp and Scheme-like languages If your performance requirements are more in the scripted range then C++ will seem like overkill. I often use python for quick and dirty tools, however every other time I end up rewriting things in C++ because something that should finish almost instantly takes half an hour.
    • nocman 4y ago
      > Sometimes the point is just having it possible. Sometimes I need to get that last bit of performance out of some code I'm talking about complexity beyond using a small subset of C++ features, things like template metaprogramming (but not limited to that). > If your performance requirements are more in the scripted range then C++ will seem like overkill. I often use python for quick and dirty tools, however every other time I end up rewriting things in C++ because something that should finish almost instantly takes half an hour. I have a wide range of requirements depending on what I am working on. I can still drop down to a C or C++ level if I need to, but if I do use C++ it will only be a limited subset that minimizes complexity. Also, you imply that Lisp and Scheme-like languages are limited to performance on par with Python or other so-called "scripting languages". There are languages in that vein that can perform very close to C's performance (Gambit Scheme being one such example). Often instead of rewriting in a lower-level language, you can use optimizations in the language to improve performance. Of course you can also just rewrite smaller portions of code in C or C++ and call that code from another language. I'm not someone who just dabbled in C++ for a little while and gave up. I have decades of experience with it. I wanted to use it beyond "C plus a little extra", but I found that the further from a C-like subset I went the more incidental complexity I had to deal with, and in the end the benefits I was looking for just never materialized.
• yazzku 4y ago
  I'm on a similar boat as others here. I used to read all of Bjarne's books back in the day. Now I barely keep up with the language, and only update my knowledge of it enough to keep up with work -- and companies usually lag several standards behind. For my side projects, I've switched to C, which has a much smaller cognitive overload and allows to me focus more on the actual problem, or garbage-collected languages when I just need something quick.
  • synergy20 4y ago
    I like C a _lot_, just wish it has more well-established data structure and algorithm collection like c++'s STL library to speed up coding, also wish it had a better way to do RAII-like resource management. Someone please invent c+ that can reuse all existing c code and even some c++ code, but more capable than c, much simpler than c++.
    • tialaramex 4y ago
      The ideas in the STL were novel enough that when it was originally opposed the C++ committee didn't really "get" it. Generic programming existed since the 1970s, but it wasn't popular until maybe this century. So there's just no way K&R C gets anything like the STL. Maybe you get stuff like a char* (these days you would write void * but that's not a thing yet) linked list? That does not sound like a better world.
      • zbird 4y ago
        One pattern (not necessarily a good one, but it's definitely used out there) is to define your "generic" code in macros, and then expose a macro such as MAKE_LIST(int) that in this case instantiates a list of int. Then you get a 'type-safe' interface, or at least more type-safe than void*, and also less annoying. And then you just abuse arrays as much as possible. For a small number of items, e.g. <100 on a modern laptop, that linear and cache-friendly search is going to beat std::map and std::unordered_map and friends.
        • 4y ago
• kllrnohj 4y ago
  Nothing about this problem seems unique to C++ or even made more difficult by C++. In most languages it's a challenge to ensure objects stay in a valid state if an exception is thrown in the middle of a series of mutations. But that's also the type of problem that you very rarely need to tackle. It's not like you're making a transactional system with rollbacks every time you want to go poke a few swing gui elements, after all.
  • layer8 4y ago
    Right. But an object being in an inconsistent/invalid state can have more serious consequences in C++ than in other languages, due to the weak typing and manual-by-default memory management. In other languages, the programs may be just as incorrect, but the consequences, when the fault arises, tend to be less fatal. Of course, such a fault can in principle still lead to lost or corrupted data, but that tends to be lesa visible than a segfault.
    • kllrnohj 4y ago
      That'd only be the case if you're not using things like unique_ptr / shared_ptr. Or if you have a really funky entangled ownership model such that a split-copy ends up leaving you in a confused ownership model such that the destructor doesn't do the right thing. And you didn't catch the exception to patch that up before propagating it. That seems like a bit of a stretch to come up with hitting such a scenario, and if you do it doesn't seem like a copy & swap idiom is really the solution.
• moreice 4y ago
  It's absolutely true that C++ is too big to keep in one's head, that doesn't mean people can't or don't care to do excellent programming in it. A good team can create quality products in any language. It's possible that your experience has the slight bias that teams that are already effective in C++ don't hire consultants to teach them C++ courses.
• cyber_kinetist 4y ago
  My sane way to use (non-modern) C++: - Use simple POD-like structs as much as possible. - Don’t be afraid of creating simple functions. Not everything has to be a method. - Only use virtual functions to create pure interfaces, don’t use them for anything more complex - Don’t use constructors for things more complex than simply initializing fields. For that, use factory functions or separate Init() methods - Make use of RAII as minimal as possible. Opt for batch construction/deletion instead of RAII-like “single” construction/deletion. - Turn off exceptions, exit early on error or return an error code/error object if recovery needs to happen. (Related to why you shouldn’t use constructors) - As a bonus, turn off RTTI. Don’t rely on dynamic_cast, you’re doing something wrong. - Allocate arrays of objects instead of unique_ptrs/shared_ptrs. Use indices instead of pointers as object handles. When objects are frequently created/deleted and indices frequently get invalidated, use generational indices. - Ownership should be centralized instead of distributed. A central store should contain arrays of various kinds of objects, and it should take care of most of the memory management (as opposed to the “modern C++” way of scattering objects on heap memory via unique_ptr/shared_ptr as much as possible).
• tammartmositzk 4y ago
  Idioms are language warts. There're the result when the language is not expressive enough to solve a certain problem. An idiom basically means "memorize this thing and use it next time you see this problem". Overload "idiom" might be the latest example. When using std::visit(), every time I have to search and put some variadic using thingy with a deduction guide. I'm with your fellow software developers, because I don't memorize any of them and I don't think it's a merit about seniority. I hope C++ doesn't have to have any more idioms in future.