Search
19 results for “DanielaKEngert”
-
constexprall the things! Since the evaluation of a constant expression never results in an erroneous behavior (EB, C++26)! (But useconstexprsince C++11)This was mentioned by many at the conference, not to forget: @DanielaKEngert, Mikhail Svetkin, and others.
@meetingcpp #cpp #cpp26 #cpp11 #meetingcpp #dev #undefined_behavior #ub #erroneous_behavior #eb
-
constexprall the things! Since the evaluation of a constant expression never results in an erroneous behavior (EB, C++26)! (But useconstexprsince C++11)This was mentioned by many at the conference, not to forget: @DanielaKEngert, Mikhail Svetkin, and others.
@meetingcpp #cpp #cpp26 #cpp11 #meetingcpp #dev #undefined_behavior #ub #erroneous_behavior #eb
-
constexprall the things! Since the evaluation of a constant expression never results in an erroneous behavior (EB, C++26)! (But useconstexprsince C++11)This was mentioned by many at the conference, not to forget: @DanielaKEngert, Mikhail Svetkin, and others.
@meetingcpp #cpp #cpp26 #cpp11 #meetingcpp #dev #undefined_behavior #ub #erroneous_behavior #eb
-
constexprall the things! Since the evaluation of a constant expression never results in an erroneous behavior (EB, C++26)! (But useconstexprsince C++11)This was mentioned by many at the conference, not to forget: @DanielaKEngert, Mikhail Svetkin, and others.
@meetingcpp #cpp #cpp26 #cpp11 #meetingcpp #dev #undefined_behavior #ub #erroneous_behavior #eb
-
constexprall the things! Since the evaluation of a constant expression never results in an erroneous behavior (EB, C++26)! (But useconstexprsince C++11)This was mentioned by many at the conference, not to forget: @DanielaKEngert, Mikhail Svetkin, and others.
@meetingcpp #cpp #cpp26 #cpp11 #meetingcpp #dev #undefined_behavior #ub #erroneous_behavior #eb
-
RE: https://mastodon.social/@zadjii/116518329631639405
One of the measurements that I've taken for my latest talk:
The *entire* API (i.e. header files) of Asio, Boost, Ceral, Eigen, Qt, Xerces, plus MS MFC, MS STL, MS Windows SDK, MS UCRT
* compiled as #include, or loaded from PCH: 2 GB
* compiled as modules (one for each library) and imported: 88 MB
-
Wat? The .cpp file you mention is nothing but a convenience wrapper for the boatload of .ipp files with the actual implementation - either #included into each consumer TU if you configure Asio as a traditional header-only library, or otherwise precompiled into an object archive. It's totally up to you.
Compilers give a damn to the extensions of the files that contain pieces of the source text. The only thing that counts is their usage.
-
In der SW-Entwicklung sprechen wir oft von "technischen Schulden".
Sollten wir diese nicht eher als "technische Schäden" bezeichnen?
"Schäden" passieren, wenn wir eine Fähigkeit nicht beherrschen, oder wenn wir unaufmerksam sind, oder wenn uns etwas egal ist. Die Folgen sind zumeist überraschend, unvorhersehbar, und nicht kalkulierbar.
"Schulden" sind zumeist das Ergebnis einer bewußten Entscheidung nach trefflicher Überlegung, mit einem Plan zur Rückzahlung.
------
In software development, we often talk about ‘technical debt’.
Shouldn’t we rather call this ‘technical damage’?
‘Damage’ occurs when we lack the necessary skills, or when we are inattentive, or when we simply don’t care. The consequences are usually unexpected, unpredictable, and impossible to quantify.
‘Debt’ is usually the result of a conscious decision made after careful consideration, with a plan for repayment.
-
CW: "colourful language" ahead
This pile of shit called CMake and package managers is happening again.
Back from the last ISO C++ meeting in Croydon where we voted on the appetite for inclusion of mp-units into the next standard, I tried to get even the *chance* to compile it using the recommended Conan, CMake, and other dependencies.
And failed spectacularly again:
* at some point, the current VS2026 compiler is spat out ("what even is this thing" coming from the attempt to deal with Catch2.Ok, switch off testing for now.
* next some complaints about "avg_speed-headers" missing some support from CMake. What the heck?
The fact that compiler options seem incomplete for full C++23 conformance is certainly only minor, right?
To me, this sounds like building with VS is seriously lacking (in particular CMake).
Therefore I will do what I usually do: move CMakeLists.txt over to a build system, that works for years now, and retain only the source tree.
-
CW: "colourful language" ahead
This pile of shit called CMake and package managers is happening again.
Back from the last ISO C++ meeting in Croydon where we voted on the appetite for inclusion of mp-units into the next standard, I tried to get even the *chance* to compile it using the recommended Conan, CMake, and other dependencies.
And failed spectacularly again:
* at some point, the current VS2026 compiler is spat out ("what even is this thing" coming from the attempt to deal with Catch2.Ok, switch off testing for now.
* next some complaints about "avg_speed-headers" missing some support from CMake. What the heck?
The fact that compiler options seem incomplete for full C++23 conformance is certainly only minor, right?
To me, this sounds like building with VS is seriously lacking (in particular CMake).
Therefore I will do what I usually do: move CMakeLists.txt over to a build system, that works for years now, and retain only the source tree.
-
CW: "colourful language" ahead
This pile of shit called CMake and package managers is happening again.
Back from the last ISO C++ meeting in Croydon where we voted on the appetite for inclusion of mp-units into the next standard, I tried to get even the *chance* to compile it using the recommended Conan, CMake, and other dependencies.
And failed spectacularly again:
* at some point, the current VS2026 compiler is spat out ("what even is this thing" coming from the attempt to deal with Catch2.Ok, switch off testing for now.
* next some complaints about "avg_speed-headers" missing some support from CMake. What the heck?
The fact that compiler options seem incomplete for full C++23 conformance is certainly only minor, right?
To me, this sounds like building with VS is seriously lacking (in particular CMake).
Therefore I will do what I usually do: move CMakeLists.txt over to a build system, that works for years now, and retain only the source tree.
-
CW: "colourful language" ahead
This pile of shit called CMake and package managers is happening again.
Back from the last ISO C++ meeting in Croydon where we voted on the appetite for inclusion of mp-units into the next standard, I tried to get even the *chance* to compile it using the recommended Conan, CMake, and other dependencies.
And failed spectacularly again:
* at some point, the current VS2026 compiler is spat out ("what even is this thing" coming from the attempt to deal with Catch2.Ok, switch off testing for now.
* next some complaints about "avg_speed-headers" missing some support from CMake. What the heck?
The fact that compiler options seem incomplete for full C++23 conformance is certainly only minor, right?
To me, this sounds like building with VS is seriously lacking (in particular CMake).
Therefore I will do what I usually do: move CMakeLists.txt over to a build system, that works for years now, and retain only the source tree.
-
CW: "colourful language" ahead
This pile of shit called CMake and package managers is happening again.
Back from the last ISO C++ meeting in Croydon where we voted on the appetite for inclusion of mp-units into the next standard, I tried to get even the *chance* to compile it using the recommended Conan, CMake, and other dependencies.
And failed spectacularly again:
* at some point, the current VS2026 compiler is spat out ("what even is this thing" coming from the attempt to deal with Catch2.Ok, switch off testing for now.
* next some complaints about "avg_speed-headers" missing some support from CMake. What the heck?
The fact that compiler options seem incomplete for full C++23 conformance is certainly only minor, right?
To me, this sounds like building with VS is seriously lacking (in particular CMake).
Therefore I will do what I usually do: move CMakeLists.txt over to a build system, that works for years now, and retain only the source tree.
-
@PeterSommerlad
Right, this is a tough challenge.Every time I thought I've found a good solution, tests with multiple compilers (possible thanks of @compiler_explorer) and different use cases, at least one of the requirements isn't met.
And then there are compiler implementation bugs. As an example: for the majority of msvc updates from the VS2019 timeframe, code execution isn't reliably stopped (or even at all) at compiletime, producting only compiler warnings. Or older gcc is in some cases totally silent, not even producing a single diagnostic.
Compiletime evaluation is one of the new C++ frontiers where QoI becomes a big differentiator.
The rules of constant expressions are not an easy read. But understanding them well is a prerequisite for e.g. becoming proficient in C++26 reflection.
-
It is stardate 01-01-2026T09:00:00, we are approaching unchartered territory. It is unclear what future will bring, but I'm already distracted:
I feel like I *need* to find a version of the well-known 'assert(boolean-expression)' from the C (and C++) standard library, that is not only compatible to the well-known runtime behaviour, *but also usable in code execution at compiletime*!
My list of requirements:
* the expression must evaluate to (void)* when the macro NDEBUG is defined.
* same when NDEBUG *is* defined, and the boolean expression in the argument to assert evaluates to something that is convertible to bool, with a value of 'true' *in the current evaluation* of said expression.
* when NDEBUG is defined, and said expression evaluates to something equivalent to 'false', further code execution must be stopped with a diagnostic message. The diagnostic must include the position in source code where the assertion fails during code execution. At runtime, the standards mandate how this is supposed to happen, but are silent about compile time.
* the assert() expression *must* be 'noexcept(true)'.
* the implementation must be immune to further advancements in compiler technology and forseeable C++ language changes. (I know, 'forseeable' and 'advancements' are vague at best).
* the implementation must *not produce* compiler warnings, even at the highest warning levels (like e.g. -Wall -Wextra -Wpedantic -Werror in clang and gcc, or /Wall /WX in msvc). In other words: the assertion must be invisible when its argument passes expectations.
* ideally, the implementation compiles in C++17 mode. This may require support from the compiler.
At present, I have an acceptable implementation but I'm not convinced to reliably meet the third and second to last requirements.
The seemingly obvious candidates for compiletime evaluation - 'static_assert()' or 'throw something' - fail to tick all marks.
Are there any ideas that I might put to test? I will then replace my current one with yours in my proposed changes Viktor Zverovitch's Żmij library that enable compile-time conversions of floating-point numbers to strings, and see how it fares.
-
Another day, and I felt like it:
The phantastic Żmij library by @vitaut , now usable at compile time!
Plus (much preferred) compile-time testing of all library test cases (expect for a single one that requires runtime-only standard library functions).
-
I'm a bit ashamed to admit that I once owned a quite extensive list of "unintended" opcodes in then popular microprocessors like the 6502 or the Z80, but somehow lost it after having finished university and moved on to later technologies. 😭
So, at some time between the end of the 80s and now, my virtual cat or imagined dog must have eaten it. 😉
May be you can still find that stuff on the interwebs, hidden somewhere in between all that AI slop. Wikipedia might help you.
To give you a hint from ancient memories: The Z80 could architecturally access its registers in both 8 bit and 16 bit chunks - except for the IX and IY ones. Documented as index registers like the well-known HL one (i.e. concatenated H and L), they were portrayed as non-splittable. But they were as people found out, giving you more independently manipulatable registers for situations where you could take advantage of that capability. The IX/IY prefixes were functional pretty much everywhere. Later implementations of the Z80 architecture may have lost that undocumented capability.
-
I'm a bit ashamed to admit that I once owned a quite extensive list of "unintended" opcodes in then popular microprocessors like the 6502 or the Z80, but somehow lost it after having finished university and moved on to later technologies. 😭
So, at some time between the end of the 80s and now, my virtual cat or imagined dog must have eaten it. 😉
May be you can still find that stuff on the interwebs, hidden somewhere in between all that AI slop. Wikipedia might help you.
To give you a hint from ancient memories: The Z80 could architecturally access its registers in both 8 bit and 16 bit chunks - except for the IX and IY ones. Documented as index registers like the well-known HL one (i.e. concatenated H and L), they were portrayed as non-splittable. But they were as people found out, giving you more independently manipulatable registers for situations where you could take advantage of that capability. The IX/IY prefixes were functional pretty much everywhere. Later implementations of the Z80 architecture may have lost that undocumented capability.
-
This is a thing now: #clang 16.0 passes my module test suite for the {fmt} library 🎉
With some additions to the primary interface unit related to the C++ standard library, it compiles the BMI and runs the test in the MSYS2 environment, too.
It looks like *importing* user-defined literals dosn't work yet: the namespace is visible, but 'operator""_cf ' isn't. This test is disabled for now.