Outdated, modern solution is baked in now https://en.cppreference.com/w/c/preprocessor/embed
It will be at least a decade before I can rely on that in systems software that needs to be portable.
C/C++ Embedded Files (2013)
21–30 of 57 posts
Re: C/C++ Embedded Files (2013)
#22Earlier quoted context omitted.
It's still lacking content that goes before/after the output. Just write a Python script that does the whole thing.
Don't know what you mean, it works fine here. Python is too large and unreliable a dependency for something so trivial (which can be accomplished using standard POSIX utilities if need be).
Python is pretty much mandatory for Linux systems nowadays, unless you're dealing with something really minimalist or trying to be very portable it's safe to rely on.
Re: C/C++ Embedded Files (2013)
#23Earlier quoted context omitted.
It's still lacking content that goes before/after the output. Just write a Python script that does the whole thing.
Don't know what you mean, it works fine here. Python is too large and unreliable a dependency for something so trivial (which can be accomplished using standard POSIX utilities if need be).
Indeed, even writing this utility in C is trivial and has 0 extra dependency for a pure C/C++ project. Avoiding #embed also removes the dependency to a C++23 capable compiler, which might not be available in uncommon scenarios.
Re: C/C++ Embedded Files (2013)
#24Earlier quoted context omitted.
Don't know what you mean, it works fine here. Python is too large and unreliable a dependency for something so trivial (which can be accomplished using standard POSIX utilities if need be).
Python is pretty much mandatory for Linux systems nowadays, unless you're dealing with something really minimalist or trying to be very portable it's safe to rely on.
> it's safe to rely on
Is there any guarantee they won't break backwards compatibility again?
Re: C/C++ Embedded Files (2013)
#25Outdated, modern solution is baked in now https://en.cppreference.com/w/c/preprocessor/embed
The thing that always irks me about c++ is this sort of thing: > Explanation 1) Searches for the resource identified by h-char-sequence in implementation-defined manner. Okay, so now I have to make assumptions that the implementation is reasonable, and won't go and "search" by asking an LLM or accidentally revealing my credit card details to a third party, right? And even if the implementation _is_ reasonable the onl…
You're not the only one who feels that way, but IMHO it's not a valid complaint.
The C++ standard says implementation defined because the weeds get very thick very quickly:
- Are paths formed with forward slash or backslash?
- Case sensitive?
- NT style drive letter or Posix style mounts?
- For relative paths, what is it relative to? When there are multiple matches, what is the algorithm to determine priority?
- What about symlinks and hard links?
- Are http and ftp URIs supported (e.g. an online IDE like godbolt). If so, which versions of those protocols? TLS 1.3+ only? Are you going to accept SHA-1?
- Should the file read be transactional?
People already complain that the C++ standard is overly complicated. So instead of adding even more complexity by redefining the OS semantics of your build platform in a language spec, they use "implementation defined" as a shorthand for "your compiler will call fopen" plus some implementation wiggle room like command line options for specifying search paths and the strategy for long paths on Windows
What if #embed steals my credit card data is a pointless strawman. If a malicious compiler dev wanted to steal your credit card data, they'd just inject the malicious code; not act like a genie, searching the C++ spec with a fine comb for a place where they could execute malicious code while still *technically* being standards conformant. You know that, I know that, we all know that. So why are we wasting words discussing it?
Re: C/C++ Embedded Files (2013)
#26Outdated, modern solution is baked in now https://en.cppreference.com/w/c/preprocessor/embed
The thing that always irks me about c++ is this sort of thing: > Explanation 1) Searches for the resource identified by h-char-sequence in implementation-defined manner. Okay, so now I have to make assumptions that the implementation is reasonable, and won't go and "search" by asking an LLM or accidentally revealing my credit card details to a third party, right? And even if the implementation _is_ reasonable the onl…
> So now I think to myself: if I want to remain portable, I'll just write a python script
How can you know that your Python implementation won't send your credit card details to an LLM when it runs your script? It does not follow an ISO standard that says it can't do that. You're not making assumptions about it's behavior, are you?
Re: C/C++ Embedded Files (2013)
#27Earlier quoted context omitted.
The thing that always irks me about c++ is this sort of thing: > Explanation 1) Searches for the resource identified by h-char-sequence in implementation-defined manner. Okay, so now I have to make assumptions that the implementation is reasonable, and won't go and "search" by asking an LLM or accidentally revealing my credit card details to a third party, right? And even if the implementation _is_ reasonable the onl…
You're not the only one who feels that way, but IMHO it's not a valid complaint. The C++ standard says implementation defined because the weeds get very thick very quickly: - Are paths formed with forward slash or backslash? - Case sensitive? - NT style drive letter or Posix style mounts? - For relative paths, what is it relative to? When there are multiple matches, what is the algorithm to determine priority? - What…
Including files also opens up some potential security issues that the standards committee just didn't want to prescribe solutions to. Compiler explorer hides easter eggs around the virtual filesystem, for example:
Re: C/C++ Embedded Files (2013)
#28Outdated, modern solution is baked in now https://en.cppreference.com/w/c/preprocessor/embed
That's good to know, but I've noticed it was added in C++26 and seems to be supported in GCC 15 and Clang 19, but not MSVC.
I think in a few (3-4?) years it will be safe to use, but in any case not now.
Still, good to know that it exists.
Re: C/C++ Embedded Files (2013)
#29Outdated, modern solution is baked in now https://en.cppreference.com/w/c/preprocessor/embed
That's good to know, but I've noticed it was added in C++26 and seems to be supported in GCC 15 and Clang 19, but not MSVC. I think in a few (3-4?) years it will be safe to use, but in any case not now. Still, good to know that it exists.
I would assume that this is easy enough to implement that it will likely appear in a minor update to the upcoming Visual Studio version. MS kept updating the compiler since VS 2022, too.
Re: C/C++ Embedded Files (2013)
#30Earlier quoted context omitted.
The thing that always irks me about c++ is this sort of thing: > Explanation 1) Searches for the resource identified by h-char-sequence in implementation-defined manner. Okay, so now I have to make assumptions that the implementation is reasonable, and won't go and "search" by asking an LLM or accidentally revealing my credit card details to a third party, right? And even if the implementation _is_ reasonable the onl…
You're not the only one who feels that way, but IMHO it's not a valid complaint. The C++ standard says implementation defined because the weeds get very thick very quickly: - Are paths formed with forward slash or backslash? - Case sensitive? - NT style drive letter or Posix style mounts? - For relative paths, what is it relative to? When there are multiple matches, what is the algorithm to determine priority? - What…
The real reason why this stuff in underspecified in the spec is that some mainframe operating systems don't have file systems in the common modern sense, but support C++. Those vendors push back a lot against narroed definitions as far as I know.