C++ really has a lot of good things. It's just a shame it's so slow to compile.
I'm curious if anybody is working to make C++ faster to compile. Even if it was a subset of the language, with some features removed, it would be good enough for me.
Yes - C++20 added support for modules to the Core Language (both "header units" and "named modules"; header units are an intermediate step between classic includes and named modules), and support for header units to the Standard Library. Compiler/library support is a work in progress (MSVC's STL, which I work on, is the furthest along - see https://github.com/microsoft/STL/issues/1694 for status), but header units are showing significant improvements in compiler throughput (build speed). This looks like `import <vector>;` in your source code (with significant build system changes to build vector as a header unit, producing vector.ifc and vector.obj).
There's a proposal under review for C++23 to add named modules for the Standard Library, see https://wg21.link/p2465r2 . If this is accepted, `import std;` (or `import std.compat;`) will be the one-line way to use the entire C++ Standard Library with (what we hope will be) even better compiler throughput.
The primary limitation of header units and especially named modules is macros: neither can be influenced by macros defined in the source file, and named modules can't emit macros at all. Thus, one will still need to `#include <cassert>` in addition to `import std;` if you want the `assert()` macro.
Currently it appears anyone that cares about bounds checking and iterator validation in release builds, has to keep using global module fragments.
The standard library modules really need to be built as part of your projects build so that you can compile them however you want.
How hard will it for library writers to supply their libraries as modules?
Will the only requirement be to remove macros?
* Use ninja instead of make
* Use PCH
* -gsplit-dwarf
Oh and of course compile errors are absolutely useless but I suppose that's a C++ thing in general. The error panel shows the (last? First?) Error in a chain of errors, which is always something deep in library code. E.g. accidentally tried to copy a non-copyable object using unique_ptr? You can't find the offending callsite, it just points you to xmemory and at best the class being wrongly used.
What I don't recommend is Eclipse - it's complex and confusing for beginners (but a bit faster than some others).
* https://github.com/apache/netbeans/tree/12.3/cpplite#cpplite
* https://github.com/apache/netbeans/blob/12.3/cpplite/cpplite...
Contrary to a sibling post eclipse CDT is fine (especially with vim bindings).
It depends what you want from your IDE maybe?
https://github.com/qt-creator/qt-creator
They offer binary releases, but it's also possible to compile from source without too much trouble. Written in C++, it's pretty snappy. Supports meson.
IME, the single best way to reduce your C++ compile times is to compile less code:
* Remove all unnecessary headers. Template expansion is slow, and preprocessing is even slower. Some of the standard includes (like `<regex>` and `<iostream>`) are notorious for slowing individual translation units to a crawl. `#pragma once` for your own headers also helps with cpp-time performance.
* Forward-declare as much as you can. Forward type declarations mean that the compiler doesn't need to process all of `Foo` when it sees `Foo&` or `Foo`.
Use pImpl wherever you can (and makes sense). Private implementations similarly reduce the amount of code the compiler needs to analyze.
For better or worse, the current winds suggest that C++ compilation times will only continue to get worse (more constexpr/consteval, even more complex templating features/concepts, etc.).
> * Forward-declare as much as you can. Forward type declarations mean that the compiler doesn't need to process all of `Foo` when it sees `Foo&` or `Foo`.
I've found the include-what-you-use (IWYU) tool [1][2] can help immensely with automating this process, especially on large code-bases.
It uses LLVM/Clang to analyze a .cpp file / translation unit and produces the minimal subset of exactly which includes are necessary and what types can be forward declared.
[1] https://include-what-you-use.org/
[2] https://github.com/include-what-you-use/include-what-you-use
Substantial improvement in compilation speed might depend on use of JIT techniques, running generated code in the compiler to perform template evaluation. I.e., a template is not just a data structure, it is a compile-time function that, where used much, is compiled to optimized machine code, its run-time values being what we think of as types. Thus far, all these functions are run like an interpreter walking a syntax tree.
Precompiled headers, or module intermediate files, could have this code in them already optimized.
I personnally use clang -ftime-trace to see which headers take the most time and then Qt Creator's "find all places where this file is included" feature to try to make the most efficient cleanups
- GCC 11 build: 4m20 (https://github.com/celtera/avendish/runs/5449993123?check_su...)
- Clang 14 build: 2m40 (https://github.com/celtera/avendish/runs/5449993033?check_su...)
Also, my understanding is that, except for the very first few prototypes, starting from cfront on the C++ compiler was a real compiler. It just happened to target C instead of asm.