Preprocessor Embed and Language Embed - The Last Sprint
https://thephd.github.io/preprocessor-embed-std-embed-the-last-spring

https://redd.it/ilomtk
@r_cpp

Should c++ just standardize an interpreted step for compilation?

Constexpr is your compiler, interpreting your code.
Right now it's weakness is it's inability and "Platformness" as described in a recent post.
But an interpreter step would solve that and many more problems.

How about actual macro system, that's not just a fancy find and replace.
Just run a for loop the types you want declared, no need for fancy template tricks.
Or how about that enum to string, string to enum generator.
Or automatic struct printing, serializing, deserializing.
\#embed? How about you just open a file and generate whatever you need with it.

It could allow for a powerful reflection step, if we let actual code touch our code.
Perhaps the @ symbol could mark areas for interpretation, just like # marks the pre processor.

C++ just has to run compiled, nothing says we can't interpret some code before hand.

So what are some problems this would fix for you today?


Also I guess i just came up with https://github.com/seanbaxter/circle.
I just remembered it last sentence, I wonder how that's going.

https://redd.it/jee26l
@r_cpp

the basic character set](https://wg21.link/P2558R0)
- [UB? In my Lexer?](https://wg21.link/P2621R0)
- [Updated wording and implementation experience for P1481 (constexpr structured bindings)](https://wg21.link/P2686R0)
- [#embed - a simple, scannable preprocessor-based resource acquisition method](https://wg21.link/P1967R0)
- [Allowing static_assert(false): To be forwarded after Issaquah unless a better proposal comes up](https://wg21.link/P2593R0)
- 4 Papers to LEWG
- [Checking if a union alternative is active](https://wg21.link/P2641R0)
- [Debugging Support](https://wg21.link/P2546R0)
- [fiber_context - fibers without scheduler](https://wg21.link/P0876R5)
- [Aggregates are named tuples](https://wg21.link/P2141R0)
- 13 Papers encouraged to come back
- [Size feedback in operator new](https://wg21.link/P0901R2)
- [Reconsidering concepts in-place syntax](https://wg21.link/P2677R0)
- Pattern Matching:
- [Exhaustiveness Checking for Pattern Matching](https://wg21.link/P2211R0)
- [A Nice Placeholder With No Name](https://wg21.link/P2169R0)
- [Pattern matching using is and as](https://wg21.link/P2392R2)
- [Pattern Matching Discussion for Kona 2022](https://wg21.link/P2688R0)
- [An error propagation operator](https://wg21.link/P2561R1)
- [C++ Ecosystem International Standard](https://wg21.link/P2656R0)
- Pointer Provenance:
- [Language support for customisable functions](https://wg21.link/P2547R0)
- [Zap the Zap: Pointers should just be bags of bits](https://wg21.link/P2188R0)
- [Nondeterministic pointer provenance](https://wg21.link/P2434R0)
- [A plan for better template meta programming facilities in C++26](https://wg21.link/P2632R0)
- [Syntax choices for generalized pack declaration and usage](https://wg21.link/P2671R0)
- 3 Lacked Consensus to Continue
- [Deprecate changing kind of names in class template specializations](https://wg21.link/P2669R0)
- [Compound Literals](https://wg21.link/P2174R0)
- [Pattern Matching with Exception Handling](https://wg21.link/P2381R0)
- Reviewed 20 Core issues assigned to EWG, Resolved 2, 17 closed as “Not a Defect”, 1 needs a paper.
- Discussed about the Val object model

For more info, see [“C++ Language Evolution status”](https://wg21.link/P1018r19)

 

*****

# Library Progress

*****

### Library Evolution Working Group (LEWG) Progress

*****

We met all 5 days of the week with a hybrid setup. Our focus was on processing the feedback that experts form the national bodies gave in the form of national body comments (NB Comments).

The regular telecoms during the year put us into a situation where we had less work in that regard which allowed us to make quite some progress on C++26 features.

The decisions for C++23 and C++26 taken at this meeting in LEWG will be confirmed by electronic polling for the benefit of people who were not able to attend.

- NB comments: 19
- C++23 papers: 12
- 26 & TS papers: 18
- C++23
- Ranges (Issues fixing, [“`views::enumerate`”](https://wg21.link/p2164))
- std::format and formatters improvements.
- `std::barrier`
- `std::start_lifetime_as` the main change proposed was dropped, the paper will only suggest the ability to allow size 0 for arrays of unknown bound ([“Fixing start_lifetime_as for arrays”](https://wg21.link/P2679R1))
- C++26
- Linear algebra / BLAS interfaces ([“A free function linear algebra interface based on the BLAS”](https://wg21.link/P1673R5))
- [“Submdspan”](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2630r1.html) and other mdspan refinements.
- [“`function_ref`: a type-erased callable reference”](https://wg21.link/P0792R11)
- Static and SBO (small buffer Optimization) vectors ([“Support for static and SBO vectors by allocators”](https://wg21.link/P2667R0))
- RCU (We discussed the topic of [“Why RCU Should be in C++26”](https://wg21.link/P2545R1))
- hazard_ptr
- Library Fundamental TS v3
- Approved in Kona, will be sent to ISO ballot for NB comments.
- We will not pursue further library fundamental TSes moving forward
-

P1967 #embed and D2752 “Static storage for initializer_list” are now on Compiler Explorer
https://quuxplusone.github.io/blog/2023/01/13/embed-and-initializer-lists/

https://redd.it/10bfkcf
@r_cpp

[C++26] Poor man's introspection with #embed
https://twitter.com/krisjusiak/status/1615086312767516672

https://redd.it/10dw6gi
@r_cpp

A paper is needed to explore this further.

Evolution also considered the following proposals to match C23 in some places:

* [`#embed` - a simple, scannable preprocessor-based resource acquisition method (P1967R10)](https://wg21.link/P1967): Evolution agrees to match C23, sent to Core.
* [Relax `va_start` requirements to match C (P2537R2)](https://wg21.link/P2537): Forward "Alternative 2" (change define, remove all but 1st sentence) to Library/Core for C++.

Evolution looked at many new C++26 features, encouraging further work on 16 topics, and reaching no consensus to continue work on 2. A few of these papers are related to safety & security.

* [A nice placeholder with no name (P2169R3)](https://wg21.link/P2169): Evolution saw issues with the implementation, would want them fixed, and would then want experience on varied C++ codebases to ensure that no breakage occurs.
* [Pack indexing (P2662R0)](https://wg21.link/P2662): Evolution encourages further work.
* [Modules: inner-scope namespace entities: exported or not? (P2640R2)](https://wg21.link/P2640): We gave feedback.
* [A minimal ADL restriction to avoid ill-formed template instantation (P2600R0)](https://wg21.link/P2600): Evolution would like to see more work in the direction of this paper, as we are motivated by the problem it is trying to solve.
* [Allow programmer to control and detect coroutine elision by `static constexpr bool should_elide()` (P2477R3)](https://wg21.link/P2477): Evolution is interested in a solution to the problem raised by this paper, in some form. We prefer the proposed alternative where the programmer has an option to prohibit elision, or to have it be an error when the optimizer fails to elide a coroutine.
* [Non-transient constexpr allocation (P2670R1)](https://wg21.link/P2670): Evolution encourages more work in the direction of `propconst` as a specifier akin to `mutable`, and would like to see this again.
* [`constexpr void*` (P2738R0)](https://wg21.link/P2738) [(P2747R0)](https://wg21.link/P2747) — Forward to Core for inclusion in C++26. The authors of P2738 and P2747 should work together and come back with reviewed wording and implementation experience.
* [`static_assert` message generation (P2741R0)](https://wg21.link/P2741) [(P2758R0)](https://wg21.link/P2758) [(N4433)](https://wg21.link/N4433): EWG would like to encourage more work on P2741R0 (`static_assert-with-constexpr-message`), solicit feedback from the Text and Unicode Study Group, then see it again with Core expert reviewed wording.
* [Pointer zap (P2188R1)](https://wg21.link/P2188) [(P1726R5)](https://wg21.link/P1726) [(P2414R1)](https://wg21.link/P2414) [(P2434R0)](https://wg21.link/P2434R0) [(P2318R1)](https://wg21.link/P2318): Guidance was given to the authors and we expect to see an omnibus solution to the problem.
* [Reconsidering concepts in-place syntax (P2677R2)](https://wg21.link/P2677): Evolution would like to see more work in this direction.
* [`is_within_lifetime` (P2641R2)](https://wg21.link/P2641): Return to Library Evolution with our blessing and recommendation that this be included in C++26.
* [Forwarding reference to specific type/template (P2481R1)](https://wg21.link/P2481): Explore this further and then come back.
* Initializing stack variables:
* [Correct and incorrect code, and what it means (P2795R0)](https://wg21.link/P2795): Evolution is interested in adding the concept of erroneous behavior as an alternative to undefined behavior, as proposed in P2795R0). Feedback was given to the author on how to increase consensus.
* [Deconstructing the avoidance of uninitialized reads of auto variables (P2754R0)](https://wg21.link/P2754): Discussed, and used to prepare for the next paper.
* [Zero-initialize objects of automatic storage duration (P2723R1)](https://wg21.link/P2723): Evolution believes zero initialization, as presented in this paper is the approach we wish to take to automatic stack variable initialization, with an opt out.
* [Type-and-resource safety in modern C++ (P2410R0)](https://wg21.link/p2410): We encourage further work on “profiles”

JeanHeyd Meneide - Implementing #embed for C and C++
https://thephd.dev/implementing-embed-c-and-c++

https://redd.it/17byq3s
@r_cpp

Proper way to call assets into the executable Pre and Post development / building?

Im building a little voxel engine / opengl project, and I need to be able to call assets from an "assets" folder in my project directory.

problem is, I keep having trouble getting the executable path, and I dont really know if theres a foolproof way to always keep track of the root project folder...

I dont really know what to do. I cant find a working method to get the executables working directory, so I cant find the assets folder...

I heard there was some new #embed feature in C23, but I have no clue how to use that either.

https://redd.it/1bq4jmy
@r_cpp

Experimenting with #embed

I recently learned that both clang and gcc have added support for [N3017](https://en.cppreference.com/w/c/preprocessor/embed) a.k.a `#embed` from C23 so naturally my first reaction was to see how well it works in C++ code.

Given this code sample:

#include <array>
#include <cstdint>
#include <experimental/array>
#include <iostream>
#include <utility>

int main() {
// works
static constexpr char c_char_array[] = {
#embed __FILE__
, '\0'
};
static constexpr unsigned char c_unsigned_char_array[] = {
#embed __FILE__
, '\0'
};
static constexpr std::uint8_t c_uint8_array[] = {
#embed __FILE__
, '\0'
};
static constexpr auto std_make_char_array = std::experimental::make_array<char>(
#embed __FILE__
, '\0'
);
static constexpr auto std_make_unsigned_char_array = std::experimental::make_array<unsigned char>(
#embed __FILE__
, '\0'
);
static constexpr auto std_make_uint8_array = std::experimental::make_array<std::uint8_t>(
#embed __FILE__
, '\0'
);
// doesn't work
// static constexpr std::byte c_byte_array[] = {
// #embed __FILE__
// , '\0'
// };
// static constexpr auto std_to_char_array = std::to_array<char>({
// #embed __FILE__
// , '\0'
// });
// static constexpr auto initializer_list = std::initializer_list<char>{
// #embed __FILE__
// , '\0'
// };

std::cout << &c_char_array;
std::cout << &c_unsigned_char_array;
std::cout << &c_uint8_array;
std::cout << std_make_char_array.data();
std::cout << std_make_unsigned_char_array.data();
std::cout << std_make_uint8_array.data();

return 0;
}

Both [gcc](https://godbolt.org/z/T9YroochP) and [clang](https://godbolt.org/z/19zf5dsWv) support the same usages as far as I tested.

What works:

* `char`, `unsigned char`, `std::uint8_t`
* C-style arrays
* `std::experimental::make_array`

What doesn't work:

* `std::byte`
* `std::initializer_list`
* `std::to_array`

I was most surprised that `std::to_array` doesn't work while `std::experimental::make_array` does, however after further investigation it seem likely that if `std::initializer_list` worked with `#embed` then `std::to_array` would as well.

It's not surprising that a C23 standard doesn't work with `std::byte` however if/when a C++ version of this paper gets added to the standard I hope that type is added to the list.

https://redd.it/1hxdv17
@r_cpp

How to implement C23 #embed in GCC 15
https://developers.redhat.com/articles/2025/01/30/how-implement-c23-embed-gcc-15

https://redd.it/1igtu7w
@r_cpp

synthesizes it into consensus, we've seen this in action in contracts to help bridge gaps that seemed unbridgeable. The thinking is that they complement each other, and are well trusted by a variety of committee members to fairly take feedback and advance this critical topic.
  This is a huge undertaking for both of them. Herb has signed up to dedicate 1.5 to 2 years of his life almost full-time on improving C++ safety and security. Thank you Herb! While Gašper wasn't here for this meeting, he's also signed up for significant work. Thank you!

# 🍱 Various C++26 papers

* ✅ [P2841](https://wg21.link/p2841r7) — [Concept and variable-template template-parameters](https://github.com/cplusplus/papers/issues/1546)
* ✅ [P2786](https://wg21.link/p2786r11) — [Trivial Relocatability For C++26](https://github.com/cplusplus/papers/issues/1463)
* ✅ [P3310](https://wg21.link/p3310r5) — [Solving issues introduced by relaxed template template parameter matching](https://github.com/cplusplus/papers/issues/1961)
* ✅ [P2719](https://wg21.link/p2719r2) — [Type-aware allocation and deallocation functions](https://github.com/cplusplus/papers/issues/1898)
* ✅ [P2866](https://wg21.link/p2866r5) — [Remove Deprecated Volatile Features From C++26](https://github.com/cplusplus/papers/issues/1556)
* ✅ [P2843](https://wg21.link/p2843r1) — [Preprocessing is never undefined](https://github.com/cplusplus/papers/issues/1548)
* ✅ [P2287](https://wg21.link/p2287r3) — [Designated-initializers for base classes](https://github.com/cplusplus/papers/issues/978)
* ✅ [P3501](https://wg21.link/P3501r0) — [The ad-dressing of cats](https://github.com/cplusplus/papers/issues/2191) (note: no cats were present)
* ✅ [P0149](https://wg21.link/D0149r2) — [Generalised member pointers](https://github.com/cplusplus/papers/issues/2223)
* ✅ [P3618](https://wg21.link/P3618r0) — [Allow attaching main to the global module](https://github.com/cplusplus/papers/issues/2237)
* ✅ [P2825](https://wg21.link/p2825r4) — [Overload resolution hook: declcall( unevaluated-call-expression )](https://github.com/cplusplus/papers/issues/1503)
* ✅ [P3492](https://wg21.link/p3492r0) — [Sized deallocation for placement new](https://github.com/cplusplus/papers/issues/2144)
* ✅ [P2952](https://wg21.link/p2952r2) — [auto& operator=(X&&) = default](https://github.com/cplusplus/papers/issues/1624)
* ✅ [P1967](https://wg21.link/p1967r14) — [\#embed - a simple, scannable preprocessor-based resource acquisition method](https://github.com/cplusplus/papers/issues/700)
* ✅ [P3540](https://wg21.link/P3540r0) — [\`#embed\` offset parameter](https://github.com/cplusplus/papers/issues/2238)
* ✅ [P1306](https://wg21.link/p1306r3) — [Expansion statements](https://github.com/cplusplus/papers/issues/156)
* ✅ [P3074](https://wg21.link/p3074r5) — [trivial unions (was std::uninitialized)](https://github.com/cplusplus/papers/issues/1734)
* ✅ [P3471](https://wg21.link/P3471r3) — [Standard Library Hardening: forward to CWG for inclusion in C++26](https://github.com/cplusplus/papers/issues/2125) this is a huge deal for safety and security
* ✅ [P3111](https://wg21.link/p3111r3) — [Atomic Reduction Operations](https://github.com/cplusplus/papers/issues/1902)
* ✅ Transactional Memory TS to a white paper
* ♻️ [P3006](https://wg21.link/P3006r2) — [Launder less](https://github.com/cplusplus/papers/issues/1703)
* ♻️ [P0876](https://wg21.link/p0876r19) — [fiber\_context - fibers without scheduler](https://github.com/cplusplus/papers/issues/117)
* 🌊 [P3568](https://wg21.link/P3568r0) — [break label; and continue label;](https://github.com/cplusplus/papers/issues/2212) (only input for WG14, with not strong preference either direction, but interested in this feature)
* ⚠️ [P2434](https://wg21.link/p2434r3) — [Nondeterministic pointer provenance](https://github.com/cplusplus/papers/issues/1364) (prospective pointer value was taken out, otherwise back in CWG)
* ❌ [P2883](https://wg21.link/p2883r1) — [\`offsetof\` Should Be A Keyword In C++26](https://github.com/cplusplus/papers/issues/1560)
* ❌ [P3477](https://wg21.link/p3477r2) —

Forwarded to EWG

* [P3412R1](https://wg21.link/P3412R1): String Interpolation — This paper proposes ‘f’ strings (and a similar ‘x’ string) that allows in-string expressions, which are handled at preprocessor time to expand to a call to std::format, or arguments compatible with std::format.
* [P3424R0](https://wg21.link/P3424R0): Define Delete with Throwing Exception Specification — This paper attempts to remove a piece of undefined behavior by making a ‘noexcept(<false-expr>)’ production deprecated, which prevents undefined behavior.
* [P2490R3](https://wg21.link/P2490R3): Zero-overhead exception stack traces — An attempt to expose stack traces in catch handlers that opt-in.
* [P3588R0](https://wg21.link/P3588R0): Allow static data members in local and unnamed classes — This paper attempts to remove an old restriction on data members of local and unnamed classes.

# Papers that got feedback and will be seen again by EWGI

* [P3550R0](https://wg21.link/P3550R0): Imports cannot… — A modules based paper that attempts to make C variadic functions ill-formed outside of the global namespace. The author received feedback that this is likely not acceptable due to type-trait-like classes.
* [P3530R0](https://wg21.link/P3530R0): Intrinsic for reading uninitialized memory — This paper explores and proposes 2 alternatives for managing uninitialized memory, and reading it in a non-undefined behavior method.
* [P3568R0](https://wg21.link/P3568R0): break label; and continue label; — This paper proposes to expose the C feature of a similar name to C++. However, this feature is contentious/has alternatives being considered, so the author requested feedback on what he could tell the WG14 committee is our preference.

 

# Core Working Group (CWG) Progress

CWG met during the full week, and reviewed papers targeting C++26, including reflection. We approved the wording for contracts, which were voted in C++26. We also approved resolutions for [CWG2549](https://wg21.link/CWG2549), [CWG2703](https://wg21.link/CWG2703), [CWG2943](https://wg21.link/CWG2943), [CWG2970](https://wg21.link/CWG2970), and [CWG2990](https://wg21.link/CWG2990).

As the next meeting (Sofia) is the last meeting for C++26 papers, our primary focus is on reviewing the wording of papers approved by EWG for C++26. most notably reflection. We will hold telecons to make progress ahead of the next meeting.

# Papers reviewed and sent to plenary (apply changes to the C++ Working Paper)

* [P3542R0](https://wg21.link/P3542R0): Abolish the term "converting constructor"
* [P3074R7](https://wg21.link/P3074): trivial unions (was std::uninitialized)
* [P1494R5](https://wg21.link/P1494): Partial program correctness
* [P2900R14](https://wg21.link/P2900): Contracts for C++
* [P3475R2](https://wg21.link/P3475): Defang and deprecate memory\_order::consume
* [P2841R7](https://wg21.link/P2841): Concept and variable-template template-parameters
* [P2786R13](https://wg21.link/P2786): Trivial Relocatability For C++26
* [P1967R14](https://wg21.link/P1967): #embed - a simple, scannable preprocessor-based resource acquisition method

# Papers which will need to be seen again by CWG

* [P2843R1](https://wg21.link/P2843R1): Preprocessing is never undefined. This paper removes UB from the preprocessor by making some constructs either ill-formed, or well-defined. We gave some feedback to the author and expect to approve it at a future meeting. This continues to remove UB outside of evaluation.
* [P2719R3](https://wg21.link/P2719R3): Type-aware allocation and deallocation functions. This paper proposes a new `new` overload taking a type\_identity. This can be used to have per-type allocation buckets, which reduces type confusion vulnerabilities. We gave feedback on the wording to the author and expect to see this again. This paper is currently targeting C++26
* [P3421R0](https://wg21.link/P3421R0): Consteval destructors
* [P2996](https://wg21.link/P2996): Reflection

 

# Library Progress

 

# Library Evolution Working Group (LEWG) Progress

 

LEWG met during the full week, and reviewed 45

Constexpr function that returns string in some form

Hello, i have cpp library that takes html string and minifies it. I want to make it constexpr but i cannot take string into constexpr function and cannot return it. If you wonder why i would want that, with combination of #embed i could embed not minified html, minify it at compile time and optimizer should only persist minified version inside binary. Somewhat related post. but i prefer gcc or clang https://www.reddit.com/r/cpp/comments/17hqbb6/constexpr\_stdstring\_msvc/

https://redd.it/1ks9rxu
@r_cpp

Modern declarative EDSL for graphic user interface in C++? Not QML or XAML.

Hello everyone,

I have been investigating lately (after using NiceGUI for a real project) and learning Jetpack Compose (not writing any real code with it, would do it with Jetpack Multiplatform if ever).

I am really impressed by Jetpack Compose approach, especially UDF.

I thought there could possibly not be a better way than MVVM tbh, after using it for years.

But after seeing how declarative composition inside the language, not with XAML or QML can be done, I am sold in the amount of boilerplate that can be saved, plus the better integration when the dsl is in the host language.

So I wanted to mention I found this, which I think could be a good start for some experiments, on top of wxWidgets: https://github.com/rmpowell77/wxUI

I think it has a talk in CppCon2025 here: https://www.youtube.com/watch?v=xu4pI72zlO4

Kudos to the author for bringing something like this to C++! Definitely useful.

I would like to hear your opinions on this style of EDSL GUI embedding and pros/cons you find for those of you who do GUI programming all the time.

Also, wild idea: with the power of compile-time C++ programming and C++26 reflection, it would be possible to get existing xaml interfaces and convert it into regular C++ at compile-time via #embed or #include and not even changing the EDSL itself and making it directly embedded and reusable in C++? That would be plenty useful.


https://redd.it/1ry51fg
@r_cpp