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