| Deutsch English Français Italiano |
|
<v5eph4$1k6a9$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!2.eu.feeder.erje.net!feeder.erje.net!news.swapon.de!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: Baby X is bor nagain Date: Tue, 25 Jun 2024 16:59:33 +0100 Organization: A noiseless patient Spider Lines: 60 Message-ID: <v5eph4$1k6a9$1@dont-email.me> References: <v494f9$von8$1@dont-email.me> <v53i4s$33k73$2@dont-email.me> <v53lf7$34huc$1@dont-email.me> <v53vh6$368vf$1@dont-email.me> <v54se1$3bqsk$1@dont-email.me> <20240624160941.0000646a@yahoo.com> <v5bu5r$va3a$1@dont-email.me> <20240624181006.00003b94@yahoo.com> <v5c86d$11ac7$1@dont-email.me> <JEheO.108086$ED9b.74955@fx11.iad> <v5cblg$11q0j$1@dont-email.me> <gEieO.108089$ED9b.25598@fx11.iad> <20240625113616.000075e0@yahoo.com> <mUzeO.141609$Cqra.55051@fx10.iad> <v5elql$1jmii$1@dont-email.me> <m3BeO.24907$Gurd.16179@fx34.iad> <v5empd$1jndv$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 25 Jun 2024 17:59:33 +0200 (CEST) Injection-Info: dont-email.me; posting-host="1ed6e99a33e78a2b7dfe692945895dda"; logging-data="1710409"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+4Pece+G233OnuHrVSYRqR" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:QmSSpjs1sw71xqU+cUdJ8eUkXNk= In-Reply-To: <v5empd$1jndv$2@dont-email.me> Content-Language: en-GB Bytes: 3604 On 25/06/2024 16:12, David Brown wrote: > On 25/06/2024 17:08, Scott Lurndal wrote: >> bart <bc@freeuk.com> writes: >>> On 25/06/2024 14:48, Scott Lurndal wrote: >> >>>>> That's why in my original post in this sub-thread, in order to give >>>>> a feeling of the size of compiler's job I gave the size of text >>>>> segment rather than size of the elf. >>>>> The size of text segment is, of course, not a good measure of >>>>> compiler's job, esp. when we are trying to compare compile jobs for >>>>> different target architectures, but it is less bad than any >>>>> alternative >>>>> measure [that is not too hard to gather] that I can think of. >>>>> If you can think about anything better, please tell us. >>>> >>>> Does the compiled code meet functional and performance specifications? >>>> >>>> That's the only criteria that matters. Size of the executable >>>> and compilation speed are basically irrelevent metrics in my >>>> experience. >>> >>> If apparently anything goes, >> >> I never said that. >> >>> and you don't care how slow a tool is or >> >> I never said that. >> >>> how big its output, how do you detect unnecessary bloat? >> >> I don't write programs with unnecessary bloat. >> >>> >>> How do you detect gratuitous use of machine resources? >> >> I write code that doesn't gratuitously use machine resources. >> > > These answers apply to me tool. > >>> >>> BTW since you and DB are both keen on products like Python, >> >> I have never posted anything about python here, that I recall. >> >> I use it very infrequently. (It seemed to be a big part of that 8Mloc project of yours) > > I /do/ use Python. I use it when it is an appropriate language to use, > which is very different circumstances from when I use C (or C++). > Different tools for different tasks. > And yet neither of you are interested in answering my question, which was why its simplistic bytecode compiler is acceptable in this scenario, but would be considered useless if applied to C code.