3 ms·

It's cool that you're using development tools that successfully parse the C++ you're working on. I found that to be a rare circumstance in any complicated code

It's cool that you're using development tools that successfully parse the C++ you're working on. I found that to be a rare circumstance in any complicated code base. And once you lose that capacity, oh boy does this language become terrible fast.

fsloth 3y ago
I think you need to define what is a complicated code base here. Visual Studio works fine for millions of lines but I am sure the difference in experience can vary wildly.
- shadowgovt 3y ago
  Visual Studio crashes on the code base I maintain. It's a monorepo using bazel to manage it, and between the sheer number of includes compilation units take, the hundred thousand plus compilation units themselves, and some decisions made early on that are hostile to VS code tooling because the original developers didn't use VS code (such as hiding template implementations in .inl files that are included in the corresponding .hh file), VS code is functionally unusable for us. In general, the company moves forward because most of the same people who established the code base are still working here and they just already know all the quirks and can Intuit argument types, often because they wrote all the classes in question.
  - fsloth 3y ago
    Ouch, my condolences.
  - ftrobro 3y ago
    Visual Studio != VS Code. I've always found Visual Studio to be great at C++ so I'm interested in knowing which of the two you meant?
    - shadowgovt 3y ago
      VSCode, to be clear. The fact that Microsoft released two products in the same domain with almost the same name consistently trips me up. No, we don't spend money on code editors around here; I meant VSCode.
      - TillE 3y ago
        Visual Studio Community is free to any company whose annual revenue is under $1 million USD. It's fully functional, unlike the ancient Express versions.
      - fsloth 3y ago
        "No, we don't spend money on code editors around here; I meant VSCode." Not spending money in tools sounds like a very strange economics for software development. If interviewing does not scare you I warmly suggest finding a new employer.
  - CyberDildonics 3y ago
    Visual Studio is not visual studio code. Also if you have a hundred thousand compilation units, it might be time for some shared libraries instead of one monolithic program.
    - shadowgovt 3y ago
      Oh I completely agree, but I am a mere senior software engineer and I have not yet figured out how to chisel past the corporate cruft of the three folks in charge of the codebase who believe monorepos are right because Google is doing it, therefore it must be the best way to do things. Nevermind that I have some experience with how Google did it, and it turns out there's a lot of ills you can solve with a 25,000+-strong engineering force that you can't in a smaller org. VSCode at Google never worked for me either, but punching a novel symbol into company-wide syntax-intelligent internal code search and glancing at the first response, which was likely to be the right one because it was a Google search engine so had well-tuned signals for "things humans care about," always did. They're not interested in how Google does it, merely that they do it so you can't get fired for making an architectural decision that worked for Google. Nor are they really interested in solving the tooling issue because it works for them; they just grep-and-pray. They're very fast at it because it's all they know so they've gotten quite good at it (when they have to do it at all; often they just know the types because they wrote the classes. ;) ).
pjmlp 3y ago
VS, QtCreator, Android Studio, KDevelop, C++ Builder,...are some of the names that come to mind where this herculean task is possible.
- shadowgovt 3y ago
  And they are, indeed, very impressive. But the nature of the language makes their task extremely difficult, and in my experience they aren't reliable. Besides the issue of C++ being just hard to compile (global symbol mutation via the macro system, the way templates instantiate, the compilation unit as the fundamental element of compilation meaning any individual compilation unit can require hundreds to thousands of include files as input), the language is rife with undefined behavior and assistive tooling is allowed to crash on undefined behavior. So, yes, if your tooling crashes it may indicate a problem with your code---but how are you going to find it now that your tooling has crashed? We've had a couple of initiatives at my organization to try and get tooling operational across the code base. They haven't stuck. Developers keep having to fall back to grep and pray. I prefer working with languages where there are simply fewer features and less undefined behavior. It makes the tooling more reliable.
  - pjmlp 3y ago
    From other comments, it doesn't seem the organisation is willing to adopt the right tools, naturally one gets what one doesn't pay for.
    - shadowgovt 3y ago
      Indeed, although I don't know what we could throw money at that would fix the problem of "Clangd crashes trying to provide LSP services for this codebase." We could buy Visual Studio and roll the dice and hope that it's more robust than vscode, but I have no particular reason to believe it would be. This organization has its work to do. My advice to other teams starting out is "C++ may be cheap in terms of hiring people and libraries that exist, but consider the cost once your codebase gets large. This is not a language that lends itself to safe behavior or tool-comprehensibility, and if that's something your project needs, be prepared for that. Other languages are safer, other languages are simpler for tooling to digest."
fluoridation 3y ago
I recently worked in a fairly large Rust project that I could simply not load into VS Code. rust-analyze would allocate more and more memory until it eventually crashed. I have never seen that with C++ code, besides that time I was investigating how someone was using CImg and found out that the CImg developers thought it was cute to make a single 3 MB header, and that brought the debugger to its knees. It still didn't crash, though! So yeah, difficult-to-parse codebases are not an exclusive feature of C++.
- shadowgovt 3y ago
  Interesting. This is the first I've heard of a Rust codebase too big to parse, but I'm not deeply surprised; Rust tooling hasn't been hammered on for as many decades as the C++ tooling. I'm medium-level confident there's meat on the bones of optimizing it to a point better than the C++ tools because they made choices in the language that do some amount of compartmentalization, so you don't get that "one #define up in this header you've never seen changes the meaning of symbols in every other file in this compilation unit." Unless that is possible and I simply haven't gotten deep enough into Rust to realize it yet.
  - fluoridation 3y ago
    Funny you should mention that. I'm pretty sure the reason this project was so difficult to process was the (IMO) abusive use of macros. I'm talking foo!( in one line, and several hundred lines below was the closing parenthesis.
    - shadowgovt 3y ago
      Macros (and in C++, their neighbor templates, since both are ways to make conditional decisions about what code to generate evaluated at compile time) are definitely the way to test out the limits of the compiler's performance. I haven't done enough Rust yet to hit this, but I don't doubt it happens. I did once make vscode scream on a very intricate family of conditional TypeScript types... Code compiled fine, but the editor started to take dozens of seconds to determine on-the-fly if types were sound. Back in the day, I once worked with a C++ game engine where the developer was obsessed with interfaces vs. implementation. Every class, even if there was one implementation, had an abstract interface wrapper. It was the first codebase I ever encountered where the compiler (on my Mac laptop) choked on it because it ran out of RAM trying to compile it.

fsloth 3y ago

I think you need to define what is a complicated code base here. Visual Studio works fine for millions of lines but I am sure the difference in experience can vary wildly.

shadowgovt 3y ago
Visual Studio crashes on the code base I maintain. It's a monorepo using bazel to manage it, and between the sheer number of includes compilation units take, the hundred thousand plus compilation units themselves, and some decisions made early on that are hostile to VS code tooling because the original developers didn't use VS code (such as hiding template implementations in .inl files that are included in the corresponding .hh file), VS code is functionally unusable for us. In general, the company moves forward because most of the same people who established the code base are still working here and they just already know all the quirks and can Intuit argument types, often because they wrote all the classes in question.
- fsloth 3y ago
  Ouch, my condolences.
- ftrobro 3y ago
  Visual Studio != VS Code. I've always found Visual Studio to be great at C++ so I'm interested in knowing which of the two you meant?
  - shadowgovt 3y ago
    VSCode, to be clear. The fact that Microsoft released two products in the same domain with almost the same name consistently trips me up. No, we don't spend money on code editors around here; I meant VSCode.
    - TillE 3y ago
      Visual Studio Community is free to any company whose annual revenue is under $1 million USD. It's fully functional, unlike the ancient Express versions.
    - fsloth 3y ago
      "No, we don't spend money on code editors around here; I meant VSCode." Not spending money in tools sounds like a very strange economics for software development. If interviewing does not scare you I warmly suggest finding a new employer.
- CyberDildonics 3y ago
  Visual Studio is not visual studio code. Also if you have a hundred thousand compilation units, it might be time for some shared libraries instead of one monolithic program.
  - shadowgovt 3y ago
    Oh I completely agree, but I am a mere senior software engineer and I have not yet figured out how to chisel past the corporate cruft of the three folks in charge of the codebase who believe monorepos are right because Google is doing it, therefore it must be the best way to do things. Nevermind that I have some experience with how Google did it, and it turns out there's a lot of ills you can solve with a 25,000+-strong engineering force that you can't in a smaller org. VSCode at Google never worked for me either, but punching a novel symbol into company-wide syntax-intelligent internal code search and glancing at the first response, which was likely to be the right one because it was a Google search engine so had well-tuned signals for "things humans care about," always did. They're not interested in how Google does it, merely that they do it so you can't get fired for making an architectural decision that worked for Google. Nor are they really interested in solving the tooling issue because it works for them; they just grep-and-pray. They're very fast at it because it's all they know so they've gotten quite good at it (when they have to do it at all; often they just know the types because they wrote the classes. ;) ).

pjmlp 3y ago

VS, QtCreator, Android Studio, KDevelop, C++ Builder,...are some of the names that come to mind where this herculean task is possible.

shadowgovt 3y ago
And they are, indeed, very impressive. But the nature of the language makes their task extremely difficult, and in my experience they aren't reliable. Besides the issue of C++ being just hard to compile (global symbol mutation via the macro system, the way templates instantiate, the compilation unit as the fundamental element of compilation meaning any individual compilation unit can require hundreds to thousands of include files as input), the language is rife with undefined behavior and assistive tooling is allowed to crash on undefined behavior. So, yes, if your tooling crashes it may indicate a problem with your code---but how are you going to find it now that your tooling has crashed? We've had a couple of initiatives at my organization to try and get tooling operational across the code base. They haven't stuck. Developers keep having to fall back to grep and pray. I prefer working with languages where there are simply fewer features and less undefined behavior. It makes the tooling more reliable.
- pjmlp 3y ago
  From other comments, it doesn't seem the organisation is willing to adopt the right tools, naturally one gets what one doesn't pay for.
  - shadowgovt 3y ago
    Indeed, although I don't know what we could throw money at that would fix the problem of "Clangd crashes trying to provide LSP services for this codebase." We could buy Visual Studio and roll the dice and hope that it's more robust than vscode, but I have no particular reason to believe it would be. This organization has its work to do. My advice to other teams starting out is "C++ may be cheap in terms of hiring people and libraries that exist, but consider the cost once your codebase gets large. This is not a language that lends itself to safe behavior or tool-comprehensibility, and if that's something your project needs, be prepared for that. Other languages are safer, other languages are simpler for tooling to digest."

fluoridation 3y ago

I recently worked in a fairly large Rust project that I could simply not load into VS Code. rust-analyze would allocate more and more memory until it eventually crashed. I have never seen that with C++ code, besides that time I was investigating how someone was using CImg and found out that the CImg developers thought it was cute to make a single 3 MB header, and that brought the debugger to its knees. It still didn't crash, though! So yeah, difficult-to-parse codebases are not an exclusive feature of C++.

shadowgovt 3y ago
Interesting. This is the first I've heard of a Rust codebase too big to parse, but I'm not deeply surprised; Rust tooling hasn't been hammered on for as many decades as the C++ tooling. I'm medium-level confident there's meat on the bones of optimizing it to a point better than the C++ tools because they made choices in the language that do some amount of compartmentalization, so you don't get that "one #define up in this header you've never seen changes the meaning of symbols in every other file in this compilation unit." Unless that is possible and I simply haven't gotten deep enough into Rust to realize it yet.
- fluoridation 3y ago
  Funny you should mention that. I'm pretty sure the reason this project was so difficult to process was the (IMO) abusive use of macros. I'm talking foo!( in one line, and several hundred lines below was the closing parenthesis.
  - shadowgovt 3y ago
    Macros (and in C++, their neighbor templates, since both are ways to make conditional decisions about what code to generate evaluated at compile time) are definitely the way to test out the limits of the compiler's performance. I haven't done enough Rust yet to hit this, but I don't doubt it happens. I did once make vscode scream on a very intricate family of conditional TypeScript types... Code compiled fine, but the editor started to take dozens of seconds to determine on-the-fly if types were sound. Back in the day, I once worked with a C++ game engine where the developer was obsessed with interfaces vs. implementation. Every class, even if there was one implementation, had an abstract interface wrapper. It was the first codebase I ever encountered where the compiler (on my Mac laptop) choked on it because it ran out of RAM trying to compile it.