8 ms·

This week I had the opportunity of revisiting C++. I had not used it in a project in nearly twenty years and I found modern C++ an absolute joy to use. Of cours

This week I had the opportunity of revisiting C++. I had not used it in a project in nearly twenty years and I found modern C++ an absolute joy to use. Of course it is still blazingly fast. But now I could build a complete app with no explicit memory management at all. Lamdas are a joy to use and integrate cleanly with STL and boost. Compiler error message are now much much better. Cross platform compatibility was awesome. The same program compiled cleanly with VC++ clang on MacOS and GCC on Linux cleanly. Finally there is a ton of documentation on every weird nuance of the language just a web search away. Both CPP reference and MSDN are just amazing. Overall I’m really happy with how much progress the language and tools have made.

whatroot8 5y ago
I’m using it for the first time and have been wondering what all the horror stories are about. But then realize those horror stories were from 15+ years ago. Did we need Rust? Or did we need to build out the C and C++ ecosystems to make them easy and safe? How many hours spent on all these languages for a few folks to build fiefdoms upon? Every human endeavor has a group of swindlers that tell you they’re helping but in hindsight often looks like they just got in the way.
- Kototama 5y ago
  Multithreaded C++ programming without bugs is still very hard. There was an interview on Mozilla and why they started Rust and everytime they had some path in the code with threads, they found some concurrency issue. I can't find the link right now. Edit: I think it's in this podcast https://corecursive.com/013-rust-and-bitter-c-developers-with-jim-blandy/ https://corecursive.com/013-rust-and-bitter-c-developers-wit...
  - PaulDavisThe1st 5y ago
    > Multithreaded C++ programming without bugs is still very hard. Multithreaded programming without bugs is hard in any language, unless the language completely cripples your ability to do certain things that tend to be where the bugs can creep in. If you religiously stick to the rules (e.g. mutexes around all variable use, mutexes and condition vars used correctly), you will not have bugs. The problems come because people do not religiously stick to the rules, because their language doesn't require them too. The problem is that if you are forced to follow all the rules, then certain things become impossible, such as lock-free programming (even the simple single-reader, single-writer FIFO). The use of memory barriers to create provably safe lock-free code is outside the scope of regularized multithreaded programming, and since it's very very hard to get that write, but people want to try it anyway, that's where things go wrong. Just use things the way you're supposed to and you won't have bugs with this.
    - lawn 5y ago
      > Just use things the way you're supposed to and you won't have bugs with this. If we humans just learned to use things we're supposed to, we would never have null pointer exceptions, issues with use-after-free nor buffer overflows. Heck, we should all just use goto while we're at it, all it takes is to religiously stick to the rules!
      - PaulDavisThe1st 5y ago
        Reasoning about null ptr, use after free, buffer overflows is tricky, because you cannot determine whether you've done the right thing by "just reading the code". If you are doing multithreaded programming, and there's a variable shared among threads, and there's a read or write of the variable without a mutex in sight, you've done it wrong. Yes, the mutex owner could be a caller several layers up the stack. Sometimes that's a legitimate design, and if you know what you're doing your function/method names will reflect the fact that the lock is already held. If you don't know what you're doing, you should avoid that design and lock the mutex in the same scope as the read/write. And of course, using RAII with C++ (or anything else that supports it) makes this sort of thing easy to do.
  - whatroot8 5y ago
    It’s all electron state in a machine. Surely very few novel code fragments are really needed to give rise to the few we find most useful. It’s all very ship of Theseus. Is it still C++ given all the change? Could we not have replaced some of the unsafe boards without tossing it all? Seems C++ did quite a bit in that direction. That manliest of conditions kicked in among computer language nerds of the 90s in their 20s, IMO. Hung up on subjective artistry and sanctimonious power plays.
- belter 5y ago
  Really? We did not need Rust? Here is what some of the best paid C++ Developers in the world come up with after billions of dollars invested in product development: https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/year-2021/opov-1/Google-Chrome.html https://www.cvedetails.com/vulnerability-list/vendor_id-1224... https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/year-2020/opov-1/Google-Chrome.html https://www.cvedetails.com/vulnerability-list/vendor_id-1224... https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/year-2019/opov-1/Google-Chrome.html https://www.cvedetails.com/vulnerability-list/vendor_id-1224... https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/year-2021/opec-1/Google-Chrome.html https://www.cvedetails.com/vulnerability-list/vendor_id-1224...
  - mempko 5y ago
    You do realize Chrome's code has a lineage that is over 24 year old, based on khtml. If you are starting a project from scratch with C++, you can avoid a lot of the pitfalls chrome's team has. Additionally Google has an arguably poor C++ coding style that is also completely out of date. A company that uses C++ more effectively is arguably Adobe, who has the great Sean Parent.
    - DSingularity 5y ago
      Can you elaborate on the code style? So many put google c++ code style on a pedestal and force it on everyone as if it is divine.
    - belter 5y ago
      Adobe as in Acrobat Reader? https://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-497/opec-1/Adobe-Acrobat-Reader.html https://www.cvedetails.com/vulnerability-list/vendor_id-53/p... or Adobe as in Photoshop? https://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-5467/opov-1/Adobe-Photoshop.html https://www.cvedetails.com/vulnerability-list/vendor_id-53/p...
    - ygjb 5y ago
      Uh, using Adobe as an argument in favour of C++ as a reliable programming language from a memory safety perspective is not a good argument. Just looking at the CVE count tells a story that cuts across their entire product line, and then we have the long and storied history of Flash and Acrobat vulnerabilities. Any non-trivial code base in any language will have security issues, but the argument that these security vulnerabilities are a result of using C++ poorly doesn't change the fact that C and C++ have tons of footguns and pitfalls based on both modern and legacy code.
- woah 5y ago
  Yes, all the Rust developers are cackling evilly in their underground lairs
- rootlocus 5y ago
  Under every modern, shiny, abstract, high-level feature of the language or the standard library there are layers and layers of legacy cruft. Every aspect the language has experimented with has to be supported by the new features, making simple things like the Variant type for example, very difficult to implement correctly [1]. C++ is nice and good until you hit a bug that leaks an abstraction and you realise you barely understand 10% of the language, and you'll never understand it completely, because people spend their entire careers trying to track down how language features interact and where they explode, and they're never finished. [1] https://www.youtube.com/watch?v=JUxhwf7gYLg https://www.youtube.com/watch?v=JUxhwf7gYLg
  - DSingularity 5y ago
    Like std::vector<bool>. Damn you std::vector<bool>.
    - skulk 5y ago
      Isn't that the poster-child of template metaprogramming? Being able to choose a different sub-byte layout for your container type depending on the type parameter? What problems are you running into when using std::vector<bool>?
      - DSingularity 5y ago
        Templating has nothing to do with my hate. It’s the fact that for all other vector types you can assume that index-based access only conflict for the same index. The only exception is… Of course it’s unlikely for you to know this because who knows all the nuances of C++ so you end up with a race in your code. Those can be very hairy to crash, reproduce, and debug.
  - belter 5y ago
    What a tour de force! Thanks for the link. It beats my previous favorite C++ presentation: "CppCon 2018: Nicolai Josuttis “The Nightmare of Initialization in C++” https://youtu.be/7DTlWPgX6zs https://youtu.be/7DTlWPgX6zs Next Halloween I will dress up as std::variant
- MR4D 5y ago
  Yes, I believe we needed Rust. Backward compatibility is valuable, but so is letting go of old habits. With C++ and Rust, we can have our cake and eat it too. Plus, arguments about which language is better! ;)
- AnimalMuppet 5y ago
  Modern C++ lets you be safe (or at least close). Rust does much more to force you to be safe. (Or, to put it differently, C++ still has all the unsafe ways available, and not locked away behind the "unsafe" keyword.)
  - bombela 5y ago
    Note that the unsafe keyword of Rust unlock only few things. But that what makes it powerful. unsafe mainly allows you to dereference pointers. References are guaranteed to be safe at all time, with an associated lifetime, while pointers can hold any possible memory address, valid or not (like in C++). unsafe also let you promote a pointer to a reference by assigning a lifetime. And finally, unsafe allows you to call functions themselves marked unsafe. One notable function is called transmute, and is very similar to how the the C style cast works in C++. It's the one that automatically selects between static_cast and reinterpret_cast depending on the context.
- bborud 5y ago
  Give it some time. If you don't think C++ is complex, you don't know C++ yet.
  - FpUser 5y ago
    It is insanely complex. Yet modern C++ is easy to use. Just don try to be Alexandrescu. I am very far from being C++ expert yet I have zero problem using it to write stateful multithreaded business servers that run for month at a time (maybe able to run for longer but I update with new features more often).
    - bborud 5y ago
      The challenge with C++ is that unless you are writing something entirely from scratch with very few third party dependencies, it quickly gets ugly because you have to deal with legacy code that wasn't written in modern C++. I've worked on projects that have started out small as well as projects that have reached (and passed) the 10M LOC mark, and this is a recurring theme. I've worked as a developer for about 35 years and I have yet to work on a C++ project where there isn't older code that has to be accommodated. Being able to write code that doesn't crash after a while isn't really a high bar.
      - FpUser 5y ago
        >"Being able to write code that doesn't crash after a while isn't really a high bar." Totally agree. >"it quickly gets ugly because you have to deal with legacy code that wasn't written in modern C++" I do not work with the projects (I assume monoliths) of such size so I guess I can count myself lucky. I would guess though that this amount of code accumulates over many years and I suspect that the majority of languages along with libs and other accompanying stuff would change as well over the time. Maybe C++ is not so special in this regard. I was hired once to fix old PHP application which was insanely giant. The type of code I saw there ranged from beautiful to making me nearly puke. It looks like the situation similar to what you've described but in completely different language. Again the cause here I think is total size, many developers coming and going and their qualifications. Also for as long as I can remember (40 years) I've almost exclusively worked on creating new products from scratch. Again extremely lucky. For new projects I would definitely advocate C++. But if one wants to do it in Rust / (insert your own favorite) for example I have nothing against it. Seems like a matter of taste to me (assuming compile times are reasonable and do not impede workflow). I would admit that I would never dare to write / mess with some code I see in system libraries or some other template heavy libraries. It can be extremely complex language wise. But I've already mentioned it in original post. Do not try to be Alexandrescu. Those are special people. And this is also special purpose type of code that is not needed for general application programming.
- tialaramex 5y ago
  > Or did we need to build out the C and C++ ecosystems to make them easy and safe? If so, the C++ committee wasn't interested in doing so. Preferring instead to say that new features don't have safety if there was any possibility that doing so might provide opportunity for improved performance. Don't worry, when inevitably you blow your feet off with any of the new footguns provided, they'll be happy to tell you that it's your fault, a true C++ programmer would have known not to do that. "Git gud" as the gamers say.
- emmanueloga_ 5y ago
  One thing that is still horrific (imho) is unicode support. Last time I found that in order to print unicode strings with cross platform support on a simple way I required a boost library [1]. The dichotomy between standard and "wide" string APIs is kind of a mess. Also, construction, destruction and move semantics makes everything really complicated and even simple baseline code requires a bunch of boilerplate [2]. 1: https://www.boost.org/doc/libs/develop/libs/nowide/doc/html/index.html https://www.boost.org/doc/libs/develop/libs/nowide/doc/html/... 2: https://gist.github.com/EmmanuelOga/12e1da5aedd9f6dc50e742cdc04fac28 https://gist.github.com/EmmanuelOga/12e1da5aedd9f6dc50e742cd...
ryanianian 5y ago
The language itself has made enormous progress, but build-systems and lower-level concerns like linkers and compiler idiosyncrasies still plague even simple projects. Tools like vcpkg paper over the horror that is cmake and more isolated build environments and could ultimately be de-facto, but even then things like mixed-version dependencies and system libraries are large barriers to entry in getting started and distributing serious work. (This applies mostly to new projects adopting modern C++. Projects that are already established in my experience don't usually have to invest much in way of their tooling and build-system provided they're not adding new dependencies or platforms on a super regular basis. We recently upgraded a 100k+ SLOC program from C++17 to C++20 and only one or two very small things failed to compile. Once the system works the system tends to stay working.) The standards committee has stayed away from delving into these issues. Perhaps with good reason. But without an official stance on how to go from "well-formed code to binaries" that covers real-world use-cases, it's hard to imagine C++ being new-learner-friendly. Perhaps modules and other newer features will obviate some of those build-like features and the problem will be more tractable by the time C++25 (?) comes around.
- PaulDavisThe1st 5y ago
  > Tools like vcpkg paper over the horror that is cmake and more isolated build environments and could ultimately be de-facto Given that I've been working with C++ for nearly 30 years, have used autotools, cmake, meson and waf but have never heard of vcpkg, it seems unlikely to me that such a thing is going to be the de facto anything. > But without an official stance on how to go from "well-formed code to binaries" that covers real-world use-cases, it's hard to imagine C++ being new-learner-friendly. Binaries are platform specific (especially installers). I don't want my language (which should almost necessarily be platform independent) grappling with or trying to tell me how to deal with them. Understanding that creating binaries is a potentially complex task that is largely (though not totally) independent of writing code is an important step for programmers working in compiled languages.
  - ryanianian 5y ago
    > have never heard of vcpkg 14.4k+ stars, and it's a product from Microsoft. It uses cmake under the covers (for now?). Doesn't mean it will win, but it's a contender. > Binaries are platform specific Yes? Each new platform has to be more or less officially adopted into a build-system. Maybe better one "official" build-system rather than dozens. Reduce the surface-area for adding a new platform and maybe it won't seem so herculean anymore. > trying to tell me how to deal with them An official build-system doesn't have to be any less feature-ful than the hodge-podge of current offerings. > creating binaries is a potentially complex task that is [...] an important step for programmers It doesn't need to be as complicated as it is today. And I don't think you intended it, but this last bit reads as dismissive and condescending. Many of us veteran C++ folks are so used to the way things have always been that it's hard to imagine an alternate universe where a sane and powerful build-system was "in the language" from the start. It may be a hard problem, but `cargo` has some interesting ideas, and I don't hear anyone complaining about not being able to do low-level and platform-specific things in Rust...
__s 5y ago
I got to revisit C++ to port some code to boost::asio It crashed because the object was deallocated by time the handler ran. So now I'm taking a shared_ptr parameter thisref parameter to keep "this" alive. Ideally it'd be a unique_ptr, but then my understanding is that ptr->func(std::move(ptr)) is undefined It's nice if these sorts of details are compiler errors, but at least there were some compiler errors: I ran into some issues over whether move being ambiguous for std::move. Took awhile figuring out where to get socket types for boost, between template parameters being duck typed & boost source being a tangle to read as documentation. Errors end up being in some header when the issue is my code somewhere passing the wrong thing Got it all sorted out eventually, but glad to get back to C/Ruby/Go/Rust programming
- pjmlp 5y ago
  That is why usually we plug stuff like SonarQube into the CI/CD pipeline.
drums8787 5y ago
Your comment is timely and encouraging for me. I last used C++ seriously in the late 90s and have thought about picking it up again to get out of my comfort zone (it's that or something like F#). I plan to play with some Wasm.
commandlinefan 5y ago
Yeah I can't help but wonder if this was written by somebody who was either too dumb to learn C++ or somebody who's hiring programmers and is angry that they're not willing to work for him for minimum wage.
FpUser 5y ago
No so long ago I rewrote sizeable python web application with C++ upon client's request. Never mind huge performance gain the C++ source code was about the same size if not shorter (do not remember exactly). And not a single explicit memory management code.

whatroot8 5y ago

I’m using it for the first time and have been wondering what all the horror stories are about. But then realize those horror stories were from 15+ years ago. Did we need Rust? Or did we need to build out the C and C++ ecosystems to make them easy and safe? How many hours spent on all these languages for a few folks to build fiefdoms upon? Every human endeavor has a group of swindlers that tell you they’re helping but in hindsight often looks like they just got in the way.

Kototama 5y ago
Multithreaded C++ programming without bugs is still very hard. There was an interview on Mozilla and why they started Rust and everytime they had some path in the code with threads, they found some concurrency issue. I can't find the link right now. Edit: I think it's in this podcast https://corecursive.com/013-rust-and-bitter-c-developers-with-jim-blandy/ https://corecursive.com/013-rust-and-bitter-c-developers-wit...
- PaulDavisThe1st 5y ago
  > Multithreaded C++ programming without bugs is still very hard. Multithreaded programming without bugs is hard in any language, unless the language completely cripples your ability to do certain things that tend to be where the bugs can creep in. If you religiously stick to the rules (e.g. mutexes around all variable use, mutexes and condition vars used correctly), you will not have bugs. The problems come because people do not religiously stick to the rules, because their language doesn't require them too. The problem is that if you are forced to follow all the rules, then certain things become impossible, such as lock-free programming (even the simple single-reader, single-writer FIFO). The use of memory barriers to create provably safe lock-free code is outside the scope of regularized multithreaded programming, and since it's very very hard to get that write, but people want to try it anyway, that's where things go wrong. Just use things the way you're supposed to and you won't have bugs with this.
  - lawn 5y ago
    > Just use things the way you're supposed to and you won't have bugs with this. If we humans just learned to use things we're supposed to, we would never have null pointer exceptions, issues with use-after-free nor buffer overflows. Heck, we should all just use goto while we're at it, all it takes is to religiously stick to the rules!
    - PaulDavisThe1st 5y ago
      Reasoning about null ptr, use after free, buffer overflows is tricky, because you cannot determine whether you've done the right thing by "just reading the code". If you are doing multithreaded programming, and there's a variable shared among threads, and there's a read or write of the variable without a mutex in sight, you've done it wrong. Yes, the mutex owner could be a caller several layers up the stack. Sometimes that's a legitimate design, and if you know what you're doing your function/method names will reflect the fact that the lock is already held. If you don't know what you're doing, you should avoid that design and lock the mutex in the same scope as the read/write. And of course, using RAII with C++ (or anything else that supports it) makes this sort of thing easy to do.
- whatroot8 5y ago
  It’s all electron state in a machine. Surely very few novel code fragments are really needed to give rise to the few we find most useful. It’s all very ship of Theseus. Is it still C++ given all the change? Could we not have replaced some of the unsafe boards without tossing it all? Seems C++ did quite a bit in that direction. That manliest of conditions kicked in among computer language nerds of the 90s in their 20s, IMO. Hung up on subjective artistry and sanctimonious power plays.
belter 5y ago
Really? We did not need Rust? Here is what some of the best paid C++ Developers in the world come up with after billions of dollars invested in product development: https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/year-2021/opov-1/Google-Chrome.html https://www.cvedetails.com/vulnerability-list/vendor_id-1224... https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/year-2020/opov-1/Google-Chrome.html https://www.cvedetails.com/vulnerability-list/vendor_id-1224... https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/year-2019/opov-1/Google-Chrome.html https://www.cvedetails.com/vulnerability-list/vendor_id-1224... https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/year-2021/opec-1/Google-Chrome.html https://www.cvedetails.com/vulnerability-list/vendor_id-1224...
- mempko 5y ago
  You do realize Chrome's code has a lineage that is over 24 year old, based on khtml. If you are starting a project from scratch with C++, you can avoid a lot of the pitfalls chrome's team has. Additionally Google has an arguably poor C++ coding style that is also completely out of date. A company that uses C++ more effectively is arguably Adobe, who has the great Sean Parent.
  - DSingularity 5y ago
    Can you elaborate on the code style? So many put google c++ code style on a pedestal and force it on everyone as if it is divine.
  - belter 5y ago
    Adobe as in Acrobat Reader? https://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-497/opec-1/Adobe-Acrobat-Reader.html https://www.cvedetails.com/vulnerability-list/vendor_id-53/p... or Adobe as in Photoshop? https://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-5467/opov-1/Adobe-Photoshop.html https://www.cvedetails.com/vulnerability-list/vendor_id-53/p...
  - ygjb 5y ago
    Uh, using Adobe as an argument in favour of C++ as a reliable programming language from a memory safety perspective is not a good argument. Just looking at the CVE count tells a story that cuts across their entire product line, and then we have the long and storied history of Flash and Acrobat vulnerabilities. Any non-trivial code base in any language will have security issues, but the argument that these security vulnerabilities are a result of using C++ poorly doesn't change the fact that C and C++ have tons of footguns and pitfalls based on both modern and legacy code.
woah 5y ago
Yes, all the Rust developers are cackling evilly in their underground lairs
rootlocus 5y ago
Under every modern, shiny, abstract, high-level feature of the language or the standard library there are layers and layers of legacy cruft. Every aspect the language has experimented with has to be supported by the new features, making simple things like the Variant type for example, very difficult to implement correctly [1]. C++ is nice and good until you hit a bug that leaks an abstraction and you realise you barely understand 10% of the language, and you'll never understand it completely, because people spend their entire careers trying to track down how language features interact and where they explode, and they're never finished. [1] https://www.youtube.com/watch?v=JUxhwf7gYLg https://www.youtube.com/watch?v=JUxhwf7gYLg
- DSingularity 5y ago
  Like std::vector<bool>. Damn you std::vector<bool>.
  - skulk 5y ago
    Isn't that the poster-child of template metaprogramming? Being able to choose a different sub-byte layout for your container type depending on the type parameter? What problems are you running into when using std::vector<bool>?
    - DSingularity 5y ago
      Templating has nothing to do with my hate. It’s the fact that for all other vector types you can assume that index-based access only conflict for the same index. The only exception is… Of course it’s unlikely for you to know this because who knows all the nuances of C++ so you end up with a race in your code. Those can be very hairy to crash, reproduce, and debug.
- belter 5y ago
  What a tour de force! Thanks for the link. It beats my previous favorite C++ presentation: "CppCon 2018: Nicolai Josuttis “The Nightmare of Initialization in C++” https://youtu.be/7DTlWPgX6zs https://youtu.be/7DTlWPgX6zs Next Halloween I will dress up as std::variant
MR4D 5y ago
Yes, I believe we needed Rust. Backward compatibility is valuable, but so is letting go of old habits. With C++ and Rust, we can have our cake and eat it too. Plus, arguments about which language is better! ;)
AnimalMuppet 5y ago
Modern C++ lets you be safe (or at least close). Rust does much more to force you to be safe. (Or, to put it differently, C++ still has all the unsafe ways available, and not locked away behind the "unsafe" keyword.)
- bombela 5y ago
  Note that the unsafe keyword of Rust unlock only few things. But that what makes it powerful. unsafe mainly allows you to dereference pointers. References are guaranteed to be safe at all time, with an associated lifetime, while pointers can hold any possible memory address, valid or not (like in C++). unsafe also let you promote a pointer to a reference by assigning a lifetime. And finally, unsafe allows you to call functions themselves marked unsafe. One notable function is called transmute, and is very similar to how the the C style cast works in C++. It's the one that automatically selects between static_cast and reinterpret_cast depending on the context.
bborud 5y ago
Give it some time. If you don't think C++ is complex, you don't know C++ yet.
- FpUser 5y ago
  It is insanely complex. Yet modern C++ is easy to use. Just don try to be Alexandrescu. I am very far from being C++ expert yet I have zero problem using it to write stateful multithreaded business servers that run for month at a time (maybe able to run for longer but I update with new features more often).
  - bborud 5y ago
    The challenge with C++ is that unless you are writing something entirely from scratch with very few third party dependencies, it quickly gets ugly because you have to deal with legacy code that wasn't written in modern C++. I've worked on projects that have started out small as well as projects that have reached (and passed) the 10M LOC mark, and this is a recurring theme. I've worked as a developer for about 35 years and I have yet to work on a C++ project where there isn't older code that has to be accommodated. Being able to write code that doesn't crash after a while isn't really a high bar.
    - FpUser 5y ago
      >"Being able to write code that doesn't crash after a while isn't really a high bar." Totally agree. >"it quickly gets ugly because you have to deal with legacy code that wasn't written in modern C++" I do not work with the projects (I assume monoliths) of such size so I guess I can count myself lucky. I would guess though that this amount of code accumulates over many years and I suspect that the majority of languages along with libs and other accompanying stuff would change as well over the time. Maybe C++ is not so special in this regard. I was hired once to fix old PHP application which was insanely giant. The type of code I saw there ranged from beautiful to making me nearly puke. It looks like the situation similar to what you've described but in completely different language. Again the cause here I think is total size, many developers coming and going and their qualifications. Also for as long as I can remember (40 years) I've almost exclusively worked on creating new products from scratch. Again extremely lucky. For new projects I would definitely advocate C++. But if one wants to do it in Rust / (insert your own favorite) for example I have nothing against it. Seems like a matter of taste to me (assuming compile times are reasonable and do not impede workflow). I would admit that I would never dare to write / mess with some code I see in system libraries or some other template heavy libraries. It can be extremely complex language wise. But I've already mentioned it in original post. Do not try to be Alexandrescu. Those are special people. And this is also special purpose type of code that is not needed for general application programming.
tialaramex 5y ago
> Or did we need to build out the C and C++ ecosystems to make them easy and safe? If so, the C++ committee wasn't interested in doing so. Preferring instead to say that new features don't have safety if there was any possibility that doing so might provide opportunity for improved performance. Don't worry, when inevitably you blow your feet off with any of the new footguns provided, they'll be happy to tell you that it's your fault, a true C++ programmer would have known not to do that. "Git gud" as the gamers say.
emmanueloga_ 5y ago
One thing that is still horrific (imho) is unicode support. Last time I found that in order to print unicode strings with cross platform support on a simple way I required a boost library [1]. The dichotomy between standard and "wide" string APIs is kind of a mess. Also, construction, destruction and move semantics makes everything really complicated and even simple baseline code requires a bunch of boilerplate [2]. 1: https://www.boost.org/doc/libs/develop/libs/nowide/doc/html/index.html https://www.boost.org/doc/libs/develop/libs/nowide/doc/html/... 2: https://gist.github.com/EmmanuelOga/12e1da5aedd9f6dc50e742cdc04fac28 https://gist.github.com/EmmanuelOga/12e1da5aedd9f6dc50e742cd...

ryanianian 5y ago

The language itself has made enormous progress, but build-systems and lower-level concerns like linkers and compiler idiosyncrasies still plague even simple projects. Tools like vcpkg paper over the horror that is cmake and more isolated build environments and could ultimately be de-facto, but even then things like mixed-version dependencies and system libraries are large barriers to entry in getting started and distributing serious work. (This applies mostly to new projects adopting modern C++. Projects that are already established in my experience don't usually have to invest much in way of their tooling and build-system provided they're not adding new dependencies or platforms on a super regular basis. We recently upgraded a 100k+ SLOC program from C++17 to C++20 and only one or two very small things failed to compile. Once the system works the system tends to stay working.) The standards committee has stayed away from delving into these issues. Perhaps with good reason. But without an official stance on how to go from "well-formed code to binaries" that covers real-world use-cases, it's hard to imagine C++ being new-learner-friendly. Perhaps modules and other newer features will obviate some of those build-like features and the problem will be more tractable by the time C++25 (?) comes around.

PaulDavisThe1st 5y ago
> Tools like vcpkg paper over the horror that is cmake and more isolated build environments and could ultimately be de-facto Given that I've been working with C++ for nearly 30 years, have used autotools, cmake, meson and waf but have never heard of vcpkg, it seems unlikely to me that such a thing is going to be the de facto anything. > But without an official stance on how to go from "well-formed code to binaries" that covers real-world use-cases, it's hard to imagine C++ being new-learner-friendly. Binaries are platform specific (especially installers). I don't want my language (which should almost necessarily be platform independent) grappling with or trying to tell me how to deal with them. Understanding that creating binaries is a potentially complex task that is largely (though not totally) independent of writing code is an important step for programmers working in compiled languages.
- ryanianian 5y ago
  > have never heard of vcpkg 14.4k+ stars, and it's a product from Microsoft. It uses cmake under the covers (for now?). Doesn't mean it will win, but it's a contender. > Binaries are platform specific Yes? Each new platform has to be more or less officially adopted into a build-system. Maybe better one "official" build-system rather than dozens. Reduce the surface-area for adding a new platform and maybe it won't seem so herculean anymore. > trying to tell me how to deal with them An official build-system doesn't have to be any less feature-ful than the hodge-podge of current offerings. > creating binaries is a potentially complex task that is [...] an important step for programmers It doesn't need to be as complicated as it is today. And I don't think you intended it, but this last bit reads as dismissive and condescending. Many of us veteran C++ folks are so used to the way things have always been that it's hard to imagine an alternate universe where a sane and powerful build-system was "in the language" from the start. It may be a hard problem, but `cargo` has some interesting ideas, and I don't hear anyone complaining about not being able to do low-level and platform-specific things in Rust...

__s 5y ago

I got to revisit C++ to port some code to boost::asio It crashed because the object was deallocated by time the handler ran. So now I'm taking a shared_ptr parameter thisref parameter to keep "this" alive. Ideally it'd be a unique_ptr, but then my understanding is that ptr->func(std::move(ptr)) is undefined It's nice if these sorts of details are compiler errors, but at least there were some compiler errors: I ran into some issues over whether move being ambiguous for std::move. Took awhile figuring out where to get socket types for boost, between template parameters being duck typed & boost source being a tangle to read as documentation. Errors end up being in some header when the issue is my code somewhere passing the wrong thing Got it all sorted out eventually, but glad to get back to C/Ruby/Go/Rust programming

pjmlp 5y ago
That is why usually we plug stuff like SonarQube into the CI/CD pipeline.

drums8787 5y ago

Your comment is timely and encouraging for me. I last used C++ seriously in the late 90s and have thought about picking it up again to get out of my comfort zone (it's that or something like F#). I plan to play with some Wasm.

commandlinefan 5y ago

Yeah I can't help but wonder if this was written by somebody who was either too dumb to learn C++ or somebody who's hiring programmers and is angry that they're not willing to work for him for minimum wage.

FpUser 5y ago

No so long ago I rewrote sizeable python web application with C++ upon client's request. Never mind huge performance gain the C++ source code was about the same size if not shorter (do not remember exactly). And not a single explicit memory management code.