Practical C++ Modules - Boris Kolpackov - CppCon 2019

[@antiHUMANDesigns]

Oh, I remember some almost 20 years ago, when I started with C/C++, and I ran into "cyclic dependencies". A strange problem for a beginner.

[@davithov]

But the fact that using headers you faced into "cyclic dependencies" is, IMO, a good thing and not bad as represented in the talk, because, when you face such issue you understand that you have design problem and it helps you to solve it.

[@retropaganda8442]

Glad to finally see a shell prompt with a distinct color rather than an all-green flow of text where we can't see where commands have been entered :)

[@dreastonbikrain1896]

hehe I was happy too, the next big step would be to use a shell which has built in syntax highlighting :D , maybe in twenty years or so XD

[@mariusbancila5627]

A couple of points came to my mind while watching this talk: 1. How do modules help the problem of splitting the code between headers and source files if we split the code between interface and implementation module units? 2. How can we build better C++ integrations from other languages by parsing and consuming BMIs if the BMI is compiler-specific?

[@ipotrick6686]

you dont have to split them anymore, you can still split the interface and implementation for some edge cases where it makes compilation a bit faster.

[@davithov]

I think the benefits of modules are much exaggerated, because even very minor details of headers are represented as a drawback. For example, they say that with headers we have to find some workarounds when speaking about implementation details. So, IMO, having unnamed namespace or static keywords in your .cpp files is not a workaround, but very nice feature/implementation detail which enables you nicely separate/make invisible a function from another translation unit. Also they talk about naming problem: in this case we use namespace. Furthermore, in case of modules we also have to use namespaces if we want to prevent such kind of errors, so there is no difference here. Also, I think that even if modules have some very minor advantages, it seems to like to invent a tank in order to kill a bug.

[@BGFutureBG]

42:01 if modules aim to replace headers, why would it be a bad idea to make a module per class?

[@davidfong]

@37:50, why would the importers of the no-split approach need to recompile when the implementation in a .mpp file changes? Is it just an assumption that the tooling wouldn't be implemented as smart enough to detect when a change to a .mpp file is only an implementation (and not an interface) change (in order to know that importers of the module don't need to be recompiled)? I assume that such a build tool optimization would be complicated/difficult to implement, but it isn't immediately obvious to me why it might be impossible. Is there a "deeper" technical limitation that prevents such an optimization? I have _no idea_ what I'm talking about and I'm probably spouting nonsense, but here's my attempt to come up with an answer I might find somewhat satisfying: I suppose if a toolchain's BMI layout internally makes some kind of BMI dependency information position-dependent, and lays out the "interface bits" of a BMI in a way that is non-stable with repect to implementation-only changes, that would be a problem. Ex. b has b_function0, which uses a_function2 from a, and the bmi format is such that b.bmi says it can find the interface info of a_function2 at byte 0x123 of a.bmi, but the bytes representing the implementation of a_function0 and a_function1 are before 0x123, so if the implementation of a_function0 or a_function1, b would definitely need to recompile/update b.bmi to point to wherever a_function2's "interface bits"'s new offset in a.bmi is. And supposing that there was a good tradeoff-related reason that such a BMI layout/repreesntation was chosen, then I would find that understandable. I'm guessing it would be really borthsome for build-systems / build-system generators like CMake if different compiler toolchains varied in whether recompilation is needed in such a scenario if they really want to make the most of possible optimizations. Again, I have no idea what I'm talking about, I know it's probably way more complicated than that. I apologize for however much my ignorance has betrayed me (and maybe annoyed you) in writing the above. I'm just trying to give an example of the level of explanation I'm curious to get. I suppose the same question goes for split hpp/cpp files- ie. "why does a simple change to a header like adding whitespace cause my build tooling to recompile all my cpp files that include that header?" I'm assuming the answer starts with something like: "it would be an absolute nightmare to implement correctly because... (reasons x y z (probably including something to do with preprocessing and macros and the complexity of parsing a programming language))", which I can appreciate. I'm happy enough that I get such powerful tools for free. @50:57 I really appreciate that the discussion is tuned for different contexts. One of the things I find a little hard about reading / listening to guidelines or suggestions about how to write code is that sometimes the guideline is mostly only relevant to one such context, and the person giving the guideline sometimes doesn't make that clear.

[@Bbdu75yg]

Amazing!

[@CppCon]

Thanks!

[@davithov]

I don't really understand when you're trying to represent headers as a disadvantages when you refer to DRY principle. So, you're saying that we have to repeat ourselves. Can you please show where we're repeating ourselves? Do you mean when we declare a function in a header, we should repeat the declaration of it in the source file as well?

[@JohnWasinger]

14:46 What is the b command run at the prompt? Is it an aliased bash script?

[@redark7]

Build2 project

[@dagoberttrump9290]

useless without cmake support :(

[@r2com641]

Guys it’s 2023 and nodules still buggy, gives Internal Compiler Error when used with std::string 👎 c++ is a joke now you can’t even finish 20 standard

[@mapron1]

I disagree with only one point: that modules solves compilation speed problem. 3-5x speed gain is almost nothing, compare what we could achieve with distributed compilation systems. And because modules almost remove ability for parallel compilation (you may not see it with 8 threads, but it is obvious like for 200 compilation threads) it is a step back in terms of speed. Despite that fact, I totatally for modules, as they bring useful abstraction and incapsulation.

[@atridas6086]

The problem with that reasoning is that headers are embarassingly parallel by duplicating an embarassing amount of work. With modules you can "cache" that part.

[@ragnarlothbrok367]

Headers should be deprecated ASAP, its a prehistoric relict and its bad for both ease of use and performance.

[@VioletGiraffe]

No, it is most certainly good for ease of use. Having an "index of contents" for a .cpp is a tremendous help when working with source code. It's one of the major reasons why unfamiliar C++ code is easier for me to understand than Java or C#.

[@Rififi50]

VioletGiraffe You can still do the same thing with modules? It’s literally a talking point in the presentation.

[@igorswies5913]

well first modules should be implemented in all major compilers without bugs before you deprecate headers

[@Elite7555]

@@VioletGiraffe That's what documentation tools are for.

[@0x1337feed]

documentation is for poorly written code and interfaces