3 ms·

Yes, as cquery's README states it has a huge memory overhead because it basically just builds the project and keeps the info around. This is rather like how Vis

by Rusky 8y ago

Yes, as cquery's README states it has a huge memory overhead because it basically just builds the project and keeps the info around. This is rather like how Visual Studio's C++ IDE support used to work, and it was not fun to wait for re-indexing after making edits. Alternative Clang-based solutions reduce the memory overhead by doing more on-demand computation, more in line with how C# or Java IDEs work, at the cost of much higher latency because Clang is not designed for anything but batch compilation. This also isn't a complete solution for accuracy, as it only really works if you're also building with Clang (or something close enough that Clang can emulate it). Like I said, things have improved for C++, but it's nowhere near what other, more IDE-friendly, languages can do.

jhasse 8y ago
My guess would be that in C# and Java, re-indexing is faster, because those languages have faster compile times in general. Therefore I would put this as a compile time problem. > This also isn't a complete solution for accuracy, as it only really works if you're also building with Clang (or something close enough that Clang can emulate it). Well that's a bit unfair, because we're talking about C++, not a GCC or MSVC extension to the language. And if there's some other compiler that isn't standard comformant, I wouldn't put this as a IDE support problem. Of course there are cases were Clang fails to compile standard C++ code, but those are very rare.
- Rusky 8y ago
  Yes- but not only are C# and Java faster to compile in general, they're easier to process small pieces of in isolation. C++ requires everything referenced to be declared previously even just to parse. (Modules should help here, at least, eventually.) But even then, parsing is often required to do complex Turing-complete processing of templates and constexpr, since that determines something's role in the grammar. This forces an accuracy vs performance tradeoff that modules don't help with at all. So it's not just a compile time problem that happens to affect IDEs, but also an IDE problem, because they can't take nearly as much advantage of the fact that they're only trying to analyze the code, not build it. And language extensions are hardly unfair. In practice they're used all over the place, and people expect them to work in their IDEs, especially when they're off in some header they didn't write. (Attributes help here, somewhat, when compiler vendors can move extensions into them.)
  - jhasse 8y ago
    Makes sense, thanks for the explanation. > And language extensions are hardly unfair. In practice they're used all over the place, and people expect them to work in their IDEs, especially when they're off in some header they didn't write. (Attributes help here, somewhat, when compiler vendors can move extensions into them.) It's a C++-as-it-is-used-in-the-wild problem then, not a (ISO) C++ one ;) Anyway: I myself never had any problems, but all my programs build fine with Clang (as all C++ programs should IMHO).

by Rusky 8y ago

jhasse 8y ago

My guess would be that in C# and Java, re-indexing is faster, because those languages have faster compile times in general. Therefore I would put this as a compile time problem. > This also isn't a complete solution for accuracy, as it only really works if you're also building with Clang (or something close enough that Clang can emulate it). Well that's a bit unfair, because we're talking about C++, not a GCC or MSVC extension to the language. And if there's some other compiler that isn't standard comformant, I wouldn't put this as a IDE support problem. Of course there are cases were Clang fails to compile standard C++ code, but those are very rare.

Rusky 8y ago
Yes- but not only are C# and Java faster to compile in general, they're easier to process small pieces of in isolation. C++ requires everything referenced to be declared previously even just to parse. (Modules should help here, at least, eventually.) But even then, parsing is often required to do complex Turing-complete processing of templates and constexpr, since that determines something's role in the grammar. This forces an accuracy vs performance tradeoff that modules don't help with at all. So it's not just a compile time problem that happens to affect IDEs, but also an IDE problem, because they can't take nearly as much advantage of the fact that they're only trying to analyze the code, not build it. And language extensions are hardly unfair. In practice they're used all over the place, and people expect them to work in their IDEs, especially when they're off in some header they didn't write. (Attributes help here, somewhat, when compiler vendors can move extensions into them.)
- jhasse 8y ago
  Makes sense, thanks for the explanation. > And language extensions are hardly unfair. In practice they're used all over the place, and people expect them to work in their IDEs, especially when they're off in some header they didn't write. (Attributes help here, somewhat, when compiler vendors can move extensions into them.) It's a C++-as-it-is-used-in-the-wild problem then, not a (ISO) C++ one ;) Anyway: I myself never had any problems, but all my programs build fine with Clang (as all C++ programs should IMHO).