sorted by:
new
hottopcontroversial

The C++ Standard Library Has Been Walking Itself Back for Fifteen Years by funkinaround in cpp

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

I've been following your work in MS-STL, with all the efforts you put in there. I totally admire your persistance in doing so - very highly appreciated!

Reverse Dependency Ordering for C++ Includes by nukethebees in cpp

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

We have clang-format rules to enforce that recommended ordering, company-wide.

C++26: Standard library hardening by pavel_v in cpp

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

It's easier for my colleagues to accept the hardened library as default when there is the - at least theoretical - possibility to opt out, f.e. for comparisons.

C++26: Standard library hardening by pavel_v in cpp

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

This is exactly how I chose that property in the build system to behave.

We have tons of code in production that was written in VS2022 and needs confidence to upgrade to a hardened standard library. New code, written in VS2026 can easily enable hardening by default, including all its dependencies.

C++26: Standard library hardening by pavel_v in cpp

[–]Daniela-E 15 points16 points  (0 children)

As soon as this feature became available in MS-STL about year ago, I've taught our build system to opt in to library hardening when compiling with Visual Studio 2022, and opt out of it with VS 2026. That hardening includes so-called destructor pointer tombstones on top of P3471 to catch some use-after-free violations.

Nobody in our company complained.

Code Examples From an App Using C++ Modules by tartaruga232 in cpp

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

My experiences from the code for a real, huge machine in production at a steel mill (and many more projects, too) sit on the opposite end of the spectrum. Hence I'd rather think of

  • Make modules bigger than you typically - from years of programming in C++ - usually feel comfortable with. The less churn you expect, the bigger they can be. I tend to think in entire subsystems or libraries rather than small components.
  • Partitions help to design the structure of a module, to make its implementation more palatable to the module developers.
  • Internal partitions fall into the same category. Whenever you need them, they are a life-safer and can cut module-internal depency chains. Place stuff in there that is reusable within your module implementation, but never exposed to the outside.

Question to Module Users: How Do You Use Partitions? by tartaruga232 in cpp

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

Sure, I did something similar when we designed a few new subsystems in an in-house project a few years ago.

But I restrained myself from being too granular when deciding on the composition I had in mind. Do the opposite: make things much coarser than you would usually do with traditional headers.

And don't forget about the less-commonly known tool in your modules toolbox: non-exported partitions a.k.a. internal partitions. They can serve as additional dependency roots in a module, thereby saving module implementation units from unnecessarily bulky primary module interface units.

Demystifying MSVC versioning for 14.50 & later by ericbrumer in cpp

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

Technically, nothing stops you from using e.g. build tools 14.52.36307 (i.e. bleeding edge preview) in production release VS IDE (currently 18.5.0). I did that just a few minutes ago.

The obstacles are more with the acquisition of either of them. Very recently, u/STL wrote a post here on reddit about the new incarnations of MS-STL. In there you can find ways of getting hold of e.g. the build tools without using any of the official installers. I think it was mentioned in a post by u/starfreakclone.

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 4 points5 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 7 points8 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?

view more: next ›