9 ms·

C++ is legacy. You can't just ignore the fundamentals.

by tw1984 4y ago

lionkor 4y ago
That doesnt change the fact that software has been written in it, and will be written in it.
- tw1984 4y ago
  Same can be said for BASIC, my favourite childhood language. you know people collect old cars, computers, stamps as hobby, tens of millions of people are into that. for the exact same reason, there will be people who are just into writing software using legacy tools. I totally understand & respect such decisions.
jahnu 4y ago
Just spent two years writing a medium size fresh c++ codebase in modern style with all the warnings turned to max and nearly every static analysis tool we could throw at it from day 1. It’s been an utter pleasure with no pain that can be blamed on c++ alone. It can be done :)
- tw1984 4y ago
  for stuff like gaming & HFT, you are probably forced to do it in C++, it is a sad reality affecting small % of developers. for everything else, if you are still building fresh new projects in C++, you are making a big mistake. C++ today is like Cobol in 2010. yes, there are reasons for them to exist, people tell your the good old days, probably some fresh good recent experience. but come on, there is a much better place for C++ - https://computerhistory.org/ https://computerhistory.org/
  - jahnu 4y ago
    As mentioned below we are doing audio plugins. Every cycle is precious to our artists. Especially since we are doing spectral effects.
    - tw1984 4y ago
      I do precise timing with accuracy up to +/- 1ns and some of my hardware are of 10-100pt resolution. I use C and Rust for such serious stuff as I don't have free time to waste to just entertain those over designed concepts like OO or STL. you need to be honest - the stdlib of C++ is not on par with the ones in rust or golang. It is more like stone age tools compared with starlink. I sincerely hope that all C++ users will be able to benefit from the networking addition to the C++ stdlib before their retirement - you know after 40 years waiting not all C++ developers had such pleasure.
      - PaulDavisThe1st 4y ago
        > more like stone age tools compared with starlink that would the starlink whose performance slowly, inexorably degrades as more and more of my neighbors start to use it?
  - mr_00ff00 4y ago
    Why is gaming and HFT forced to be C++? Just that code already exists in C++ and you need to expand on it? Gaming has Unreal but surely you could use another game engine without C++?
    - lordnacho 4y ago
      Simply put cpp gives you ultimate control. If you want to be absolutely economical with the CPU/memory, you need to do things likely preallocate memory and making sure you don't get cache misses and branch mispredicts. For most software, the hardware has already run away to the point where you can just sort of tell the machine roughly what to do and it will do it for you in a way that doesn't affect your task, so you don't have to fiddle with minutiae like where exactly to place a thing in memory.
      - mr_00ff00 4y ago
        So Rust can’t do that quite as well?
        lordnacho 4y ago
        I think it gets close. Certainly close enough that if you're a small team doing similar things, use Rust. If you have time to fiddle with the little things, go with cpp.
    - lenkite 4y ago
      Rust doesn't even have support for custom allocators in the language/stdlib. Still waiting on https://github.com/rust-lang/rust/issues/42774 https://github.com/rust-lang/rust/issues/42774. bumpalo doesn't cut it. Funny thing is that boring and sensible Go just came out with arenas support.
  - deleted 4y ago
    [deleted]
- drdrey 4y ago
  In the audio plugin space?
  - jahnu 4y ago
    Yep! We release the same plugins on Windows, macOS and iOS so we get great coverage with compilers too. I should set up a build for Linux with gcc but haven’t had the time yet.
    - tw1984 4y ago
      cross-platform is no longer a bonus of a language or a toolchain. it is a must to have feature in any modern language. to give you some example - using the exact same toolchain on amd64/macos, I can build my golang code to run natively on risc-v/linux or arm64/windows. everything happens within seconds as I just need to override two environmental variables. there is no "haven't had the time yet" problem in such modern languages. it is by design, in the very core of the language and its native toolchain.
      - PaulDavisThe1st 4y ago
        WTF are you talking about. first of all, audio plugins come in a variety of formats, some of which are 100% platform specific (AudioUnits, Apple, I'm looking at you). You can be using the same toolchain across N platforms, but that won't make any difference to the fact that you're having to generate code that integrates with multiple syntactically and semantically distinct APIs. secondly, in the audio plugin space, SIMD is often a vitally important tool. no cross-compiler or cross-architectural tools there, unless you opt for a common denominator so low it's not really worth anything. You want SIMD? You can't use anything that crosses compiler and/or architecture boundaries to any meaningful extent. thirdly, in the audio plugin space, you need to create GUIs that run inside the host application. there's no good solutions for this that span linux/macos/windows, though there is the not-so-good solution of using JUCE ... except that a solid chunk of the folks who use JUCE don't use the GUI part at all. the idea that this stuff could ever be a feature of the language and span even just those 3 OS'es is ridiculous assertion and I wager will never be realized. there is no standard C++ GUI API for good reason, and the same reasons are why there will never be one for Rust or golang either. Just look at the list of GUI toolkit crates floating around out there already. fourthly, "building" doesn't just mean compiling. the process of creating a packaged audio plugin will vary by plugin format, and by platform, and is often one of the most critical tasks that is so often slightly screwed up. once again, golang and rust are never going to contain builtin tools for this process - that's going to have to come from some other layer of your toolchain. granted, portable build tools do exist, but they are almost necessarily language agnostic and thus violate your assertion that it must be a part of the language's "native toolchain". the process of creating working software in general often transcends the language specific parts. once you have a set of object files, creating an executable has as much to do with the OS process launch conventions as anything in the language used to create the object files.
- jerf 4y ago
  I personally consider C or C++ written with the best-of-breed static analysis deployed on it, preferably from day one, to essentially be a different language. Most of the criticisms of C or C++ are eliminated under this setup. You get different ones; the resulting language is even more complex than the base languages, and requires an even deeper understanding of what's going on, but at least you have the requisite support to learn it, so in the end it's probably a net positive even in terms of the ability to learn it. This is, obviously, a very opinionated opinion. If I was going to be forced to do it, this is how I'd want to do it.
  - nhooyr 4y ago
    What static analysis tools are you referring to for C?
- TheDesolate0 4y ago
  [dead]
- John23832 4y ago
  I think that's great if you're writing from scratch, but I think it misses the point that the previous poster was making. Modern "pleasant" C++ is a subset of all of C++. In the realm of all C++, you can get into some REALLY bad code. That includes terse C. I work in the NYC market, and have bounced between finance and tech. The quality of C++ at a tech company, even legacy code, is magnitudes better than the stuff in finance.
  - jahnu 4y ago
    Yeah I did a few years in finance on a c++98 code base for my sins. (My colleagues were great, but the code was not optimal to say the least. Then again I really loved making it better and faster.) My intention above was just to say experiences with c++ vary with circumstances and if you are lucky legacy isn’t part of your day to day :) I’m lucky ;)
- ryandrake 4y ago
  Most of the stereotypical pain of C++ lives in legacy codebases where they're passing raw pointers all over the place, doing horrible things with array indexes, and poorly re-implementing the standard library containers. If you start from a base of modern C++, embrace the standard library and newer, safer data structures, it's a pleasure!
  - WkndTriathlete 4y ago
    > If you start from a base of modern C++, embrace the standard library and newer, safer data structures, it's a pleasure! I write software in probably a dozen languages, including C++, and using the features/STL in C++17/C++20 in no way makes using C++ a "pleasure", it simply makes using C++ "less painful". If I want to present information processing applications to users, it's C#/Java (or Kotlin, or Scala, or F#) with some Typescript front-end and likely some form of SQL simply because those are the tools that enable me to accomplish the job the fastest with the highest quality. If I need software to work in or with embedded systems then I grab C simply because it's the tool that enables me to accomplish the job the fastest with the highest quality. If I need some software to bridge those two worlds then I reach for C++ because it's the only tool that efficiently bridges the gap. And C++ sucks, even with C++17/C++20/STL because I can't tell from the STL documentation which pieces manage memory for me and which I have to remove on my own and when this memory management (sometimes) magically occurs. I know what it is with C, because it's all malloc()/free(), and I know what it is with JVM/C#, because it's managed for me, but with C++ it's an incomprehensible mess. Don't even get me started on the half-assed implementation of lambdas vs. function pointers vs. std::function and which can be used where and where the const/reference operators have to go.
    - devnullbrain 4y ago
      It sounds like you simply don't know RAII.
    - blub 4y ago
      Have a gut feeling that polyglots can’t handle C++ so well because their strategies for using several languages fail: one has to know C++ well in order to be able to use it successfully. I know C++ memory management like the back of my hand and much of the STL (with some C++17+ exceptions) by heart. But even though I’ve used both C# and Java in the past and could jump back in, my working knowledge of those languages right now is near zero. Polyglots truly are jacks of all trades and masters of none.
- remexre 4y ago
  Which static analysis tools do you recommend?
  - jahnu 4y ago
    We compile with msvc so we use those built in analysis tools and also the Xcode analysis tools, and clang-tidy! And of course checking with ASan. I may have exaggerated with the “nearly every” sorry! But we do use sufficiently enough tools to avoid most of the pain of c++
- Shorel 4y ago
  I only have a small codebase, but I mirror the sentiment. If you care about it, it can and will be done. Same, all warnings enabled, compiles and runs in both AMD and ARM processors, it is just 20 to 40 times faster than the thing it replaced, I really can't complain. C++ gets underserved hate by people who don't care about doing a good job anyway.
coldtea 4y ago
"Legacy" is meaningless in the contect you've used it. C++ has wide use, and will continue to have huge use, for both old, current, and new codebases, in tons of areas, from systems, finance, and OS, to scientific and games.
29athrowaway 4y ago
Think of the most modern technologies today. Almost in every case, you'll find C++ at the core of them.

C++ is legacy. You can't just ignore the fundamentals.

by tw1984 4y ago

C++ is legacy. You can't just ignore the fundamentals.

lionkor 4y ago

That doesnt change the fact that software has been written in it, and will be written in it.

tw1984 4y ago
Same can be said for BASIC, my favourite childhood language. you know people collect old cars, computers, stamps as hobby, tens of millions of people are into that. for the exact same reason, there will be people who are just into writing software using legacy tools. I totally understand & respect such decisions.

jahnu 4y ago

Just spent two years writing a medium size fresh c++ codebase in modern style with all the warnings turned to max and nearly every static analysis tool we could throw at it from day 1. It’s been an utter pleasure with no pain that can be blamed on c++ alone. It can be done :)

tw1984 4y ago
for stuff like gaming & HFT, you are probably forced to do it in C++, it is a sad reality affecting small % of developers. for everything else, if you are still building fresh new projects in C++, you are making a big mistake. C++ today is like Cobol in 2010. yes, there are reasons for them to exist, people tell your the good old days, probably some fresh good recent experience. but come on, there is a much better place for C++ - https://computerhistory.org/ https://computerhistory.org/
- jahnu 4y ago
  As mentioned below we are doing audio plugins. Every cycle is precious to our artists. Especially since we are doing spectral effects.
  - tw1984 4y ago
    I do precise timing with accuracy up to +/- 1ns and some of my hardware are of 10-100pt resolution. I use C and Rust for such serious stuff as I don't have free time to waste to just entertain those over designed concepts like OO or STL. you need to be honest - the stdlib of C++ is not on par with the ones in rust or golang. It is more like stone age tools compared with starlink. I sincerely hope that all C++ users will be able to benefit from the networking addition to the C++ stdlib before their retirement - you know after 40 years waiting not all C++ developers had such pleasure.
    - PaulDavisThe1st 4y ago
      > more like stone age tools compared with starlink that would the starlink whose performance slowly, inexorably degrades as more and more of my neighbors start to use it?
- mr_00ff00 4y ago
  Why is gaming and HFT forced to be C++? Just that code already exists in C++ and you need to expand on it? Gaming has Unreal but surely you could use another game engine without C++?
  - lordnacho 4y ago
    Simply put cpp gives you ultimate control. If you want to be absolutely economical with the CPU/memory, you need to do things likely preallocate memory and making sure you don't get cache misses and branch mispredicts. For most software, the hardware has already run away to the point where you can just sort of tell the machine roughly what to do and it will do it for you in a way that doesn't affect your task, so you don't have to fiddle with minutiae like where exactly to place a thing in memory.
    - mr_00ff00 4y ago
      So Rust can’t do that quite as well?
      - lordnacho 4y ago
        I think it gets close. Certainly close enough that if you're a small team doing similar things, use Rust. If you have time to fiddle with the little things, go with cpp.
  - lenkite 4y ago
    Rust doesn't even have support for custom allocators in the language/stdlib. Still waiting on https://github.com/rust-lang/rust/issues/42774 https://github.com/rust-lang/rust/issues/42774. bumpalo doesn't cut it. Funny thing is that boring and sensible Go just came out with arenas support.
- deleted 4y ago
  [deleted]
drdrey 4y ago
In the audio plugin space?
- jahnu 4y ago
  Yep! We release the same plugins on Windows, macOS and iOS so we get great coverage with compilers too. I should set up a build for Linux with gcc but haven’t had the time yet.
  - tw1984 4y ago
    cross-platform is no longer a bonus of a language or a toolchain. it is a must to have feature in any modern language. to give you some example - using the exact same toolchain on amd64/macos, I can build my golang code to run natively on risc-v/linux or arm64/windows. everything happens within seconds as I just need to override two environmental variables. there is no "haven't had the time yet" problem in such modern languages. it is by design, in the very core of the language and its native toolchain.
    - PaulDavisThe1st 4y ago
      WTF are you talking about. first of all, audio plugins come in a variety of formats, some of which are 100% platform specific (AudioUnits, Apple, I'm looking at you). You can be using the same toolchain across N platforms, but that won't make any difference to the fact that you're having to generate code that integrates with multiple syntactically and semantically distinct APIs. secondly, in the audio plugin space, SIMD is often a vitally important tool. no cross-compiler or cross-architectural tools there, unless you opt for a common denominator so low it's not really worth anything. You want SIMD? You can't use anything that crosses compiler and/or architecture boundaries to any meaningful extent. thirdly, in the audio plugin space, you need to create GUIs that run inside the host application. there's no good solutions for this that span linux/macos/windows, though there is the not-so-good solution of using JUCE ... except that a solid chunk of the folks who use JUCE don't use the GUI part at all. the idea that this stuff could ever be a feature of the language and span even just those 3 OS'es is ridiculous assertion and I wager will never be realized. there is no standard C++ GUI API for good reason, and the same reasons are why there will never be one for Rust or golang either. Just look at the list of GUI toolkit crates floating around out there already. fourthly, "building" doesn't just mean compiling. the process of creating a packaged audio plugin will vary by plugin format, and by platform, and is often one of the most critical tasks that is so often slightly screwed up. once again, golang and rust are never going to contain builtin tools for this process - that's going to have to come from some other layer of your toolchain. granted, portable build tools do exist, but they are almost necessarily language agnostic and thus violate your assertion that it must be a part of the language's "native toolchain". the process of creating working software in general often transcends the language specific parts. once you have a set of object files, creating an executable has as much to do with the OS process launch conventions as anything in the language used to create the object files.
jerf 4y ago
I personally consider C or C++ written with the best-of-breed static analysis deployed on it, preferably from day one, to essentially be a different language. Most of the criticisms of C or C++ are eliminated under this setup. You get different ones; the resulting language is even more complex than the base languages, and requires an even deeper understanding of what's going on, but at least you have the requisite support to learn it, so in the end it's probably a net positive even in terms of the ability to learn it. This is, obviously, a very opinionated opinion. If I was going to be forced to do it, this is how I'd want to do it.
- nhooyr 4y ago
  What static analysis tools are you referring to for C?
TheDesolate0 4y ago
[dead]
John23832 4y ago
I think that's great if you're writing from scratch, but I think it misses the point that the previous poster was making. Modern "pleasant" C++ is a subset of all of C++. In the realm of all C++, you can get into some REALLY bad code. That includes terse C. I work in the NYC market, and have bounced between finance and tech. The quality of C++ at a tech company, even legacy code, is magnitudes better than the stuff in finance.
- jahnu 4y ago
  Yeah I did a few years in finance on a c++98 code base for my sins. (My colleagues were great, but the code was not optimal to say the least. Then again I really loved making it better and faster.) My intention above was just to say experiences with c++ vary with circumstances and if you are lucky legacy isn’t part of your day to day :) I’m lucky ;)
ryandrake 4y ago
Most of the stereotypical pain of C++ lives in legacy codebases where they're passing raw pointers all over the place, doing horrible things with array indexes, and poorly re-implementing the standard library containers. If you start from a base of modern C++, embrace the standard library and newer, safer data structures, it's a pleasure!
- WkndTriathlete 4y ago
  > If you start from a base of modern C++, embrace the standard library and newer, safer data structures, it's a pleasure! I write software in probably a dozen languages, including C++, and using the features/STL in C++17/C++20 in no way makes using C++ a "pleasure", it simply makes using C++ "less painful". If I want to present information processing applications to users, it's C#/Java (or Kotlin, or Scala, or F#) with some Typescript front-end and likely some form of SQL simply because those are the tools that enable me to accomplish the job the fastest with the highest quality. If I need software to work in or with embedded systems then I grab C simply because it's the tool that enables me to accomplish the job the fastest with the highest quality. If I need some software to bridge those two worlds then I reach for C++ because it's the only tool that efficiently bridges the gap. And C++ sucks, even with C++17/C++20/STL because I can't tell from the STL documentation which pieces manage memory for me and which I have to remove on my own and when this memory management (sometimes) magically occurs. I know what it is with C, because it's all malloc()/free(), and I know what it is with JVM/C#, because it's managed for me, but with C++ it's an incomprehensible mess. Don't even get me started on the half-assed implementation of lambdas vs. function pointers vs. std::function and which can be used where and where the const/reference operators have to go.
  - devnullbrain 4y ago
    It sounds like you simply don't know RAII.
  - blub 4y ago
    Have a gut feeling that polyglots can’t handle C++ so well because their strategies for using several languages fail: one has to know C++ well in order to be able to use it successfully. I know C++ memory management like the back of my hand and much of the STL (with some C++17+ exceptions) by heart. But even though I’ve used both C# and Java in the past and could jump back in, my working knowledge of those languages right now is near zero. Polyglots truly are jacks of all trades and masters of none.
remexre 4y ago
Which static analysis tools do you recommend?
- jahnu 4y ago
  We compile with msvc so we use those built in analysis tools and also the Xcode analysis tools, and clang-tidy! And of course checking with ASan. I may have exaggerated with the “nearly every” sorry! But we do use sufficiently enough tools to avoid most of the pain of c++
Shorel 4y ago
I only have a small codebase, but I mirror the sentiment. If you care about it, it can and will be done. Same, all warnings enabled, compiles and runs in both AMD and ARM processors, it is just 20 to 40 times faster than the thing it replaced, I really can't complain. C++ gets underserved hate by people who don't care about doing a good job anyway.

coldtea 4y ago

"Legacy" is meaningless in the contect you've used it. C++ has wide use, and will continue to have huge use, for both old, current, and new codebases, in tons of areas, from systems, finance, and OS, to scientific and games.

29athrowaway 4y ago

Think of the most modern technologies today. Almost in every case, you'll find C++ at the core of them.