Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Sat, 1 Jun 2024 11:37:45 +0100
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <v3etlq$2o0sh$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me>
 <00297443-2fee-48d4-81a0-9ff6ae6481e4@gmail.com>
 <v2lji1$1bbcp$1@dont-email.me> <87msoh5uh6.fsf@nosuchdomain.example.com>
 <f08d2c9f-5c2e-495d-b0bd-3f71bd301432@gmail.com>
 <v2nbp4$1o9h6$1@dont-email.me> <v2ng4n$1p3o2$1@dont-email.me>
 <87y18047jk.fsf@nosuchdomain.example.com>
 <87msoe1xxo.fsf@nosuchdomain.example.com> <v2sh19$2rle2$2@dont-email.me>
 <87ikz11osy.fsf@nosuchdomain.example.com> <v2v59g$3cr0f$1@dont-email.me>
 <v30l15$3mcj6$1@dont-email.me> <v30lls$3mepf$1@dont-email.me>
 <v30sai$3rilf$1@dont-email.me> <v320am$1km5$1@dont-email.me>
 <v33ggr$e0ph$1@dont-email.me> <v34bne$i85p$1@dont-email.me>
 <v3758s$14hfp$1@raubtier-asyl.eternal-september.org>
 <v38of2$1gsj2$1@dont-email.me> <v39v87$1n7bk$1@dont-email.me>
 <v3du4s$2febh$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 01 Jun 2024 12:37:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="91ec5d79126354b953c01cb00293891d";
	logging-data="2884497"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18HL4bi/RBR8Sacv9ooJAUX"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:vDfxaGxAeVdmZiGINpQXwR+mBhE=
Content-Language: en-GB
In-Reply-To: <v3du4s$2febh$3@dont-email.me>
Bytes: 3691

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]