vector-of-bool

> Single-Page-Apps can be fantastic. Most teams will mess them up because most teams operate in dysfunctional organisations. I don't think the vector-of-bool website, and the broken JS transitions, were designed by a dysfunctional organization (or an organization for that matter) (though the author has suffered from burnout: https://vector-of-bool.github.io/2019/05/23/signals.html).

Check out DDDS' documentation, that's what you want: https://vector-of-bool.github.io/docs/dds/index.html It took me a few minutes following the tutorial to get my project to build on Windows, macOS, and Linux.

Is there any new reason to believe that? What I had seen--and which I would have thought would be obvious--is that the C++ module design only helps at lower levels of parallelism and actually slows down the build dramatically at the higher levels of parallelism used by people who actually care about build performance; this is apparently because the inherent design of modules causes the same kind of pervasive coupling seen with Rust, destroying the inherent scalability of the classic C++ separate compilation model. https://vector-of-bool.github.io/2019/01/27/modules-doa.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1441r1.pdf > Expectedly, as hardware parallelism increases, headers’ lead over modules becomes more and more pronounced. There is also a relationship between the DAG-depth (i.e. The length of the chain of modules that import each other). As this depth increases, modules grow slower and slower, while headers remain fairly constant for even “extreme” depths approaching 300).

I think different people will have different answers. The biggest complaint is that this slows down builds, of course, but it also requires hacks to avoid re-including the same header twice when you have complex header hierarchies [1][2], bleed-trough of macros and pragmas, and of course you have to write forward declarations for everything you intend to publicly expose, as opposed to using a "public" keyword. Honestly I dislike them because they're a redundant pain in the ass. I tried other solutions before (at one job I had 15 years ago we had automatic header code generation, ooof), and although modules are not that ready for primetime [3] (dependency resolution need to be done by an external program), I think they'll be the bees knees. [1] https://en.wikipedia.org/wiki/Include_guard [2] (some people will be quick to note that can be solved by pragmas) [3] https://vector-of-bool.github.io/2019/01/27/modules-doa.html (but he wrote a follow up: https://vector-of-bool.github.io/2019/03/04/modules-doa-2.html )

Seriously, why? They are broken. https://vector-of-bool.github.io/2019/01/27/modules-doa.html

Looking more into this, I found this document with details about the popularity of different alternative directory names: “Project Layout - Survey Results and Updates” https://vector-of-bool.github.io/2018/09/16/layout-survey.html There is also a separate proposal from around the same time, dated one month later and very focused on C++ which I find less useful for C: “Canonical Project Structure” https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1204r0.html

I've heard discussions that C++ modules didn't really give that much performance benefits as it initially claimed, when the dependency graph is huge and you have a large number of threads. Some links: - https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1441r1.pdf - https://vector-of-bool.github.io/2019/01/27/modules-doa.html Are there any notable new updates related to this controversy?

https://vector-of-bool.github.io/2019/03/04/modules-doa-2.html The issue was that there's no language level definition of module implementation and layout so every build system may need to handle every single module implementation differently. The standard body decided to publish a technical report on this issue to ensure some level of interoperability across module implementations.

For those wondering, the content seems to start about halfway down: https://vector-of-bool.github.io/2020/01/06/new-decade.html#a-new-tool The docs similarly don't seem to include a concise explanation but at least are a bit more readable: https://vector-of-bool.github.io/docs/dds/guide/packages.html I don't really see it either, my typical C++ project is okay with the library management the different *make tools offer. But C++ is not my go to language these days, I'm usually rather careful on which dependencies take on in those projects and where they come from, not really sure a npm/maven dependency model is something I would want there.

Templates are duck typing at C++ compile time (which is their runtime). Yes, concepts should help. 'Modules via copy-and-paste' (= #include) is what I would hurl at C++ these days. Though they are working on that as well, I heard. Though https://vector-of-bool.github.io/2019/01/27/modules-doa.html doesn't sound hopeful.

So the aforementioned death-on-arrival [1] was premature? Are there really implementations which end up faster as a result? [1] https://vector-of-bool.github.io/2019/01/27/modules-doa.html

This is a bad answer too, IMO. I think there is a solid case for the existence of undefined behavior; even Rust has it, it's nothing absurd in concept, and you do describe some reasoning for why it should probably exist. However, and here's the real kicker, it really does not need to exist for this case. The real reason it exists for this case is due to increasingly glaring deficiencies in the C++ language, namely, again, the lack of any form of pattern matching for control flow. Because of this, there's no way for a library author, including the STL itself, to actually handle this situation succinctly. Undefined behavior indeed should exist, but not for common cases like "oops, I didn't check to see if there was actually a value here before accessing it." Armed with a moderately sufficient programming language, the compiler can handle that. Undefined behavior should be more like "I know you (the compiler) can't know this is safe, but I already know that this unsafe thing I'm doing is actually correct, so don't generate safeguards for me; let what happens, happen." This is what modern programming languages aim to do. C++ does that for shit like basic arithmetic, and that's why we get to have the same fucking CVEs for 20+ years, over and over in an endless loop. "Just get better at programming" is a nice platitude, but it doesn't work. Even if it was possible for me to become absolutely perfect and simply just never make any mistakes ever (lol) it doesn't matter because…

modules were my #1 wanted feature in C++, but they are very disappointing to me: - they allow `.` in their names to signify hierarchy, but have no built-in notion of hierarchy or submodule. This means possible error messages will have to be suboptimal - they are orthogonal to namespaces, meaning if you have a module `foo.bar` any identifier it will export will be in the global namespace unless you put it in the `foo::bar` namespace in the `foo.bar` module file. As a user this means that I can import a `foo.bar` module and expect symbols to be imported in any namespace. - btw, what happens if different modules import the same name? I'll let you guess:-D. Modules were the chance to eliminate this kind of issues by eliminating the notion of shared namespaces, but oh well... - modules have interface units, implementation units, partitions, interface partition and implementation partition. There must be exactly one non partition interface unit, called the primary module interface. Instead of, you know, just having modules and submodules files like all modern module systems in existence. - Modules add new and fun ways to get ill-formed, no diagnostic required programs. Such as not re-exporting all interface partitions. I really hoped that modules were the chance of introducing a simpler compilation model for C++. I'm not pleased with the result. Some references: [0]: https://vector-of-bool.github.io/2019/01/27/modules-doa.html [1]:…

See also: Are modules fast? https://bfgroup.github.io/cpp_tooling_stats/modules/modules_perf_D1441… One reason why this might not be so simple is that what is often measured as a potential for speed improvement is I/O, as in "lines of code a compiler needs to read to process a translation unit". However what happens is that C++ compilers are usually CPU-bound, not I/O bound. What happens also is that C++, very differently from idiomatic C, Pascal, Modula, and their successors, has no clear separation between declaration and use of an interface, as not functions, but classes form the main interface, and what defines a class is the signature of its member functions and its members, and to know the size of the class, the size of its members need to be known, which has the consequence that the C++ compiler needs to read recursively everything which the class is defined with. This is a big difference to modula etc. Also, of course the reading of data can be cached, but the question is how much the expansion of the read text can be cached - for example some will have different semantics if the DEBUG macro is set, or some WIN_xyz macro. As far as I understand, compilers supporting C++ modules will only cache the latest expansion. Also, the build system with modules is likely to become more complex, with additional dependencies. I do not know whether this is still actual in every aspect (it could be that what is allowed to go into a module header has been narrowed down a…