Am 05.04.2022 um 15:11 schrieb René Ferdinand Rivera Morell via Boost:
On Tue, Apr 5, 2022 at 7:54 AM Horváth V.<friendlyanon_@hotmail.com> wrote:
I highly doubt it. Something I noticed is that a lot of people raise compile times as a reason they don't want to use Boost and modules supposedly help with
On 2022. 04. 05. 14:46, René Ferdinand Rivera Morell via Boost wrote: that.
The gains to be had depend highly on both the code structure and project structure (both of the modules and the user code). The gains are almost entirely in the re-parsing. I.e. they are not going to help much on the template instantiation.
Partially true. During the compilation of the module interface unit, the following is done: 1) all parsing. That alone is a big win, in particular with Boost and its boatload of includes. 2) all name lookup that can be done in translation phase 7 is performed. In addition, all template instantiations that can be done during the compilation of that TU are done. 3) all overload resolution within the overload sets formed in 2) is done. The less unsolicited unqualified name lookup is asked for by the source, the more work can be shifted to the one-time compilation of the module interface. I've seen too many template-heavy libraries in my life that seem to be totally unaware of that. The split between visibility of names and reachability of semantic properties is all but irrelevant in the traditional header world but plays a vital role in the modules world.
Which, IIRC, is the larger of the compile time complaints for Boost. But someone would have to do some performance analysis of a good size project that uses Boost in a compiler that supports such perf inspection to really know.
Ciao Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5