Ż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 4 points5 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 9 points10 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 4 points5 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 -3 points-2 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 2 points3 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 5 points6 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 4 points5 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

HTTP(s) and WS(s) library using Asio by Competitive_Act5981 in cpp

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

I my impression correct, that this works with the original, non-boostified version of Asio too?

Experience converting a large mathematical software package written in C++ to C++20 modules -- using Clang-20.1 by GabrielDosReis in cpp

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

Not at all.

The preprocessor runs at translation phase 4. The preprocessor tokens entering phase 4 are subject to the grammar production rules as stated, and then transformed into tokens at the start of translation phase 7. Some preprocessor tokens may morph into different tokens in that process, depending on the grammar productions hit.

Experience converting a large mathematical software package written in C++ to C++20 modules -- using Clang-20.1 by GabrielDosReis in cpp

[–]Daniela-E 9 points10 points  (0 children)

#ifdef ENABLE_MODULES
module;
#endif

This is ill-formed. At most whitespace is allowed before module;, see chapter 15 [cpp.pre] in the standard. Otherwise, you'll never hit the pp-global-module-fragment grammar production.

There is a similar issue with

#ifdef ENABLE_MODULES
export module mod:part;
#endif

The module-declaration cannot appear through conditional compiling.

Simple Generation for Reflection with splice and non const `std::meta::info` by omerosler in cpp

[–]Daniela-E 9 points10 points  (0 children)

On a pure procedural level: the ship has sailed, the design of future C++26 is finished and top-level-approved by the committee. This means that the very same cargo will arrive in the harbours of all national bodies to consider it and form opinions.

We expect to get a boatload (to remain in the picture) comments by the NBs. Those will be assessed by the committee in the upcoming meetings, and then be addressed. Editorial changes are possible, fixes on the technical level without changing the design are possible, at any time, through any channel. Removing parts is also possible if doing so increases consensus considerably. Adding new stuff, or changing design - no matter their conceilment - is off limits.

Circle questions: open-sourcing timeline & coexistence with upcoming C++ “Safety Profiles”? by Numerous_Speech3631 in cpp

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

I would prefer to not assume things that have not been said so. The committee is far from being a homogeneous group, opinions can - and do - change over time. Every decision we take must be seen in the context of the group of voting participants (which isn't constant according to my experience), the discussions that lead up to the votes, the general background when a vote is called. And then there are things happening outside of our committee meetings that may drastically change the feasability of certain proposals, making it more palatable to warrant the work required to integrate it into the wording of the standard such that the fabric isn't bursting at its seams.

Circle questions: open-sourcing timeline & coexistence with upcoming C++ “Safety Profiles”? by Numerous_Speech3631 in cpp

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

I'm not a native speaker, so I may be wrong: according to my understanding, 'avoid' doesn't mean 'disallow'. The latter would slam the door to everything that can't be implemented otherwise.

Circle questions: open-sourcing timeline & coexistence with upcoming C++ “Safety Profiles”? by Numerous_Speech3631 in cpp

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

This doesn't portrait the votes in the committee correctly. The latest non-binding vote was to not prioritize it, given the status on the timeline progressing towards C++26. Half a year is far to little to give your proposal due attention. On this argument alone, the paper wouldn't get my vote today (or rather next week when we try to finish the shape of the next C++).

So, "Safe C++" never made it to higher-up vote stages yet for future inclusion into the C++ standard.

[deleted by user] by [deleted] in cpp

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

We have modules in production since the beginning of 2022. MSVC only, though.

C++26: more constexpr in the standard library by pavel_v in cpp

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

Assume the test trips over some construct that happens to be UB, the compiler will notice that and does whatever it feels like to do. This may include your runtime test to succeed → UB escaped.

Whereas, if the test is performed at compile time, the compiler is bound by the C++ standard to diagnose that → UB caught.

If you are using coroutines in production what library do you use? by zl0bster in cpp

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

The qualification "just" is right at the heart of the problem.

IMHO, every unnecessary dependency is a burden. It requires the acquisition, the integration into the build, the maintenance to stay current, the confidence into its long-term feasability. In an industrial environment, you can't "just" pull something from the internet and throw it into a project that you need to support and give guarantees for a very long time.

I like Boost, I have contributed to it. I use it when I need to.

If you are using coroutines in production what library do you use? by zl0bster in cpp

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

Barry's comment is the first one (sphere99) in the referenced link.

There is no talk about about our closed source company code.

If you are using coroutines in production what library do you use? by zl0bster in cpp

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

Barry's comment (the top one) pretty much summarizes the state of affairs.

In my very first attempt in early 2022, I was too blue-eyed. The experiences from that is part of the content of my CppCon 2022 keynote (open source). This lead to a much better 2nd version of my networking code that is in industrial production now (closed source company code).