Re: C23 thoughts and opinions

On 30/05/2024 10:09, Michael S wrote:

On Thu, 30 May 2024 02:32:03 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
 

On Wed, 29 May 2024 13:58:20 +0200, Bonita Montero wrote:
>

I've got a small commandline-tool that makes a const'd char
-array from any binary file.

>
It seems to me it would be more efficient to use objcopy to turn that
binary file directly into an object file with symbols accessible from
C code defining its beginning and ending points. Then just link it
into the executable.

 Of course, it is more efficient.
But:
- it covers fewer use cases.
- it exposes array's name and size as global symbols which is not
   always desirable
- it feels too much like a magic. It would feel less like a magic if
   done by compiler rather than by extra tool. Even better if done by
   compiler in standardized manner.
 But yes, in real life, in embedded software project, that's what I'd do.
 

In real life, in embedded software projects, I'd use xxd or a few lines of Python and have an initialised const array in the code.  Why would you use something that "feels like magic" (i.e., may be mystical and hard to understand for other developers) and is more limited?  To save three seconds of build time on the rare occasions when the source binary changes?
Writing C (or C++) programs to generate these initialise files can be fun and instructive - I think we've all learned a little about where the bottlenecks really are as a result of your code.  But it is not for real-life usage.
#embed will be convenient for many common cases.  For anything that #embed can't handle, I'd need a project-specific script anyway (such as for collecting all the files in a directory and building structures to access them).  And then it is all about developer convenience - spending hours extra on the code to spare a few seconds of build time makes no sense.