Re: C23 thoughts and opinions

On 01/06/2024 02:39, Lawrence D'Oliveiro wrote:

On Thu, 30 May 2024 14:34:00 +0100, bart wrote:
 

On 30/05/2024 03:32, Lawrence D'Oliveiro 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.

>
None of my compilers, whether for C or anything else, generate object
files.

 That’s too bad. All the good compilers, for languages like C and others
which are meant to execute efficiently, do.

What do you mean by 'are meant to execute efficiently'? Is that build-time or run-time of the resulting program?
In the latter case, whether it uses object files is irrevant.
For build-time, pointlessly generating a discrete object file will slow things down.
My compilers don't routinely generate object files, which would also need an external dependency (a linker), but they can do if necessary (eg. to statically link my code into another program with another compiler).
The compiler for my main language is a whole-program one. If it were to create an object file, it would be a single file; there would be no others to link to!
And here, makefiles also assume independent compilation of modules.
So it is makefiles that appear to be holding back advancement in this area, by requiring traditional module-at-a-time building, and requiring object file intermediates.
   C:\qx52>mm -obj qq
   Compiling qq.m to qq.obj
   C:\qx52>dir qq.obj
   01/06/2024  11:34           787,788 qq.obj
   C:\qx52>gcc qq.obj -oqq            # 'link'
   C:\qx52>qq
   Q5.2 Interpreter
   Usage:
           qq filename[.q]