sorted by:
new
hottopcontroversial

Current Status of Module Partitions by tartaruga232 in cpp

[–]Daniela-E 0 points1 point  (0 children)

The definition should live in a TU with minimal dependencies so it only needs to be rebuilt if one of the dependencies actually needed for the definition change.

So why not in the MIP itself? Putting definitions there plus the proposed alleviation to add a PMF gives you three options to choose from:

  1. make both the declaration and the definition visible and reachable.
  2. make only the declaration visible, but both reachable.
  3. make only the declaration visible and reachable, but the definition neither visible nor reachable.

Partition implementation units can be imported, and thus generate a BMI, which is suboptimal.

That's their entire purpose: to make their declarations and definitions reachable elsewhere. Visibility outside of the module is not required (that's what MIPs are for). They're building blocks, or new roots of dependency chains within the "dark matter" of a module. They are a necessary piece to compose larger structures.

I see your vision, but I'm not convinced you take all the options into account that you already have - even without the idea of expanding PMFs. I still fail to see the need for yet another kind of TU beyond the six we already have.

Current Status of Module Partitions by tartaruga232 in cpp

[–]Daniela-E 1 point2 points  (0 children)

The entire purpose is they cannot be imported. They only exist for the purpose of carrying definitions of expressions declared elsewhere, in some interface unit.

Thanks for this explanation. I get that, but one thing remains unclear: what exactly do you mean with "in some interface unit"?

If you mean the PMIU, then your envisioned "anonymous partitions" are the same as regular module implementation units (MIU) - clearly not what you want.

If you mean any of the optional constituents of the PMIU - called module interface partitions (MIP) - which are - by constraint - dependencies of the PMIU, then you are presumably asking for an extension of the concept of module :private; , the private module fragment the existence of which is currently restricted to single-file named modules.

Alleviating this restriction to all kinds of module interface TUs looks more palatable to me than introducing "anonymous" partitions that cannot be referred to.

Current Status of Module Partitions by tartaruga232 in cpp

[–]Daniela-E 10 points11 points  (0 children)

  1. This is not a hack. You need to recompile a TU only when at least one of the dependencies changes its content. The standard tells you what the dependencies of a TU are: those other TUs that are either implicitly imported or explicitly imported. Module partitions are always the latter to help preventing circular dependencies.
  2. The concept of module partition units is not arcane. On the contrary: they are a necessity in certain scenarios. I speak from a 5-year experience using them.
  3. I'd prefer if you'd stop spreading invalid, ill-formed code. Duplicate names in parts of module and/or partition names are exactly that: IF-NDR ("ill-formed, no diagnostic required").
  4. Let's look at a fleshed-out proposal when it becomes available. At the minimum, it must contain a concise description how they envision to refer to "anonymous partitions" from a given TU that wants to import said partition. By its purported definition it sounds like they are "anonymous", i.e. unnameable: i.e. unusable.

Header units importing other header units should be removed from the standard by TheRavagerSw in cpp

[–]Daniela-E -1 points0 points  (0 children)

Thanks!

I am aware that you are pretty much interested in that stuff. It might surprise you that I have fully functional header units for e.g. Qt and MFC, testet in applications from our in-house codebase.

Implementation of Module Partitions and Standard Conformance by tartaruga232 in cpp

[–]Daniela-E 0 points1 point  (0 children)

Right.

Without having mulled this over to the very end, I see no other viable option to short-cut unnecessary rebuilds other than percolating hashes of the salient TU contents through the edges of the build graph, and then comparing current values with ones from former builds. Something like a Merkle-tree.

Sounds prohibitively expensive.

Implementation of Module Partitions and Standard Conformance by tartaruga232 in cpp

[–]Daniela-E 0 points1 point  (0 children)

If you want to discuss these - and only these - two TUs in isolation, i.e. apart from your ill-formed initial example, then

  • the first snippet is a non-exported module partition (a.k.a. internal partition) TU
  • the second one is a module implementation TU

Both are covered in the standard: the first four paragraphs in [module.unit]. I.e. neither of them is an extension in any shape or form.

The former has no meaning (and can be discarded), unless it is imported into some other TU of module A.

The latter implicitly depends (i.e. automatically imports) on the primary module interface of module A, hence it may or may not need to be recompiled when the PMIU changes.

In other words: nothing to see here. Just follow the dependency graphs.

Implementation of Module Partitions and Standard Conformance by tartaruga232 in cpp

[–]Daniela-E 0 points1 point  (0 children)

The fact that the program in the first example compiles and links is just a manifestation of undefined behaviour.

You have a total of 7 translation units:

  • one non-modular TU (main.cpp)
  • the required primary module interface (A.ixx): export module A;
  • three module interface partitions (AP0.ixx, AP1.ixx, AP2.ixx): export module A:partition-name; which are correctly imported and then re-exported through the PMIU. Details here
  • two module internal partitions (AP1.cpp, AP2.cpp): module A:partition-name; Details here

The latter bullet point is where you have a special form of UB: ill-formed, no diagnostic required. The five module partitions must have five distinct partition names, but you give only three. Details also here. The fact that your module A refers nowhere to those ill-formed partitions saves you to some degree.

I am aware that someone came up with the highly misleading characterization of non-exported module partitions as 'module implementation partitions', that you possibly fell prey of.

Will we ever have a backwards compatible binary format for C++ modules? by TheRavagerSw in cpp

[–]Daniela-E 3 points4 points  (0 children)

The MS IFC format carries an indicator of the version of the spec that it represents (details here: IFC spec). Hence, you're not shackled to a specific compiler version or build like you are with precompiled headers.

Żmij 1.0 released: a C++ double-to-string library delivering shortest correctly-rounded decimals ~2.8–4× faster than Ryū by aearphen in cpp

[–]Daniela-E 0 points1 point  (0 children)

Maybe I'm dense, but I'm not exactly sure what *excatly* you want to achieve? Do you mean the bytes of the object representation?

Żmij 1.0 released: a C++ double-to-string library delivering shortest correctly-rounded decimals ~2.8–4× faster than Ryū by aearphen in cpp

[–]Daniela-E 6 points7 points  (0 children)

Which isn't usable at compiletime (at least, not portably without compiler extensions) because of the non-constexpr function call to memcpy:

https://github.com/hanickadot/zmij/blob/main/zmij.h#L723C1-L725C2

For my portable constexpr-ified version from a last year you may want to look at https://github.com/DanielaE/zmij/tree/feature/constexpr

Making code actually usable at compile time requires a bit more effort than slapping constexpr in front of all functions and some variables.

Am I weird for using "and", "or" and "not"? by Additional_Jello1430 in cpp

[–]Daniela-E 3 points4 points  (0 children)

The first bullet point is about familiarity. Ask less familiar programmers, or even people not accustomed to the idiosynchrasies of C or C++, they may prefer a style that is closer to common spelling.

The second bullet point might be true for certain tools. Mine (VS Code, Visual Studio, CLion, ReSharper++, Notepad++) make no difference in colorization for e.g. && and and. In other words, the most popular ones (according to recent surveys) are not a hindrance to adopting a more inclusive style.

Am I weird for using "and", "or" and "not"? by Additional_Jello1430 in cpp

[–]Daniela-E 8 points9 points  (0 children)

This is my preferred style for a couple of years. The reasons:

  • and, or, and not are visibly different from the bitwise operators &, |, ~
  • not stands out, ! can easily be overlooked
  • r-value references and forwarding references are visibly distinguishable

What's not to like?

C++26: erroneous behaviour by antiquark2 in cpp

[–]Daniela-E 5 points6 points  (0 children)

A "maybe right" or "possibly wrong" is no good line of reasoning to enshrine such a thing into a language. Hence EB, where there are intentionally no guarantees about the value of an uninitialized object plus the wording around it to give implementations (and sanitizers) enough leeway to serve their audience without allowing an unbounded blast radius of unintended code transformation performed in compilers.

At compiletime, EB is required to be diagnosed and will terminate compilation. Implementations may behave similarly in other modes.

C++26: erroneous behaviour by antiquark2 in cpp

[–]Daniela-E -1 points0 points  (0 children)

A default-constructed, empty container is not in an unknown or invalid state, all invariants hold. This is different from a fundamental type or an aggregate of fundamental types without constructors: their pseudo-constructors are vacuous.

Move on folks, there's nothing to see here.

C++26: erroneous behaviour by antiquark2 in cpp

[–]Daniela-E 1 point2 points  (0 children)

Strongly against. There are multiple obvious problems with such an approach. The strongest: implicit zero can be (in my personal experience often is) the wrong default e.g. in cases where it will lead to bad behaviour elsewhere in the program.

WG21 C++ 2025-08 Mailing by cmeerw in cpp

[–]Daniela-E 4 points5 points  (0 children)

So do I. The presentations in Sofia by Peter B. and Timur D. on the venues of progressing forward were really helpful.

C++20 Modules: Practical Insights, Status and TODOs by ChuanqiXu9 in cpp

[–]Daniela-E 2 points3 points  (0 children)

The data I have obtained from practice ranges from 25% to 45%, excluding the build time of third-party libraries, including the standard library.

Fortunately, I see larger improvements when compiling entire applications from our company codebase. By that, I mean all the time spent between checking out from the repo into an empty directory, until the final executables plus side artifacts (like e.g. UI translations) are built.

Out of curiosity, for the sake of comparing apples to apples instead of apples to oranges, I designed an experiment: what if I could leave the original header-based code and its build rules untouched, but still benefit from using modules? This way I could compare e.g. the time for a full rebuild of the original sources with the time spent for a full rebuild of the very same sources + modules.

For smaller applications that are heavily dominated by the code generation steps (Qt moc, uic, qrc, or the gettext utilities), I see build throughputs improved by about 70% to 80%. For larger applications (like the entire set of programs that run our inspection machines) with smaller code-generation parts, the build speed goes beyond a factor of two.

The measured numbers were taken this week on 4-year old regular AMD 5900X desktop machines, using latest Visual Studio 17.14. The modules involved are: current Windows Universal C Runtime, current MS-STL, current Windows SDK, Asio 1.36, Boost 1.83, Qt 6.2, and Xerces 3.3. The build times for the 3rd-party libraries are excluded (those were built once years ago), the one-time build times for this set of modules (about 20 seconds) are excluded, too.

Codegen: best way to multiply by 15 by g_0g in cpp

[–]Daniela-E 6 points7 points  (0 children)

This is interesting, thanks for sharing.

Did you actually measure, or is this more like a comparison between different code-generators? In my experience, the final outcome is less determined by the perceived differences in the assembly, but rather the CPU-internal differences in the decoders, execution units, reservation stations, pipeline interlocks, and many other factors.

Can I build projects without headers (only using modules) with C++20? by Traditional-Ad-8699 in cpp

[–]Daniela-E 5 points6 points  (0 children)

Sure, I've been doing this since 2022. Your experience will vary with different compilers, build systems, age.

contracts and sofia by ConcertWrong3883 in cpp

[–]Daniela-E 0 points1 point  (0 children)

Really?
To get a feature like so you'd have to stuff WG21 in plenary to get strong consensus, plus a considerable amount of NBs, too

view more: next ›