| Deutsch English Français Italiano |
|
<vrnoft$15f6n$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: bart <bc@freeuk.com> Newsgroups: comp.lang.c Subject: Re: Suggested method for returning a string from a C program? Date: Sun, 23 Mar 2025 01:34:54 +0000 Organization: A noiseless patient Spider Lines: 187 Message-ID: <vrnoft$15f6n$1@dont-email.me> References: <vrd77d$3nvtf$2@dont-email.me> <20250319115550.0000676f@yahoo.com> <vreuj1$1asii$4@dont-email.me> <vreve4$19klp$2@dont-email.me> <20250319201903.00005452@yahoo.com> <86r02roqdq.fsf@linuxsc.com> <vrh1br$35029$2@dont-email.me> <LRUCP.2$541.0@fx47.iad> <vrh71t$3be42$1@dont-email.me> <874izntt5t.fsf@nosuchdomain.example.com> <vrhviu$h5c$1@dont-email.me> <87ecyrs332.fsf@nosuchdomain.example.com> <vri9t1$a29t$1@dont-email.me> <20250320171505.221@kylheku.com> <vrif1v$c9ev$3@dont-email.me> <8734f7rw7z.fsf@nosuchdomain.example.com> <vrjjvb$1esjh$1@dont-email.me> <87tt7mqk7w.fsf@nosuchdomain.example.com> <vrkvt5$2k04q$2@dont-email.me> <87cye9afl0.fsf@nosuchdomain.example.com> <vrmckn$114k$1@dont-email.me> <871puoag2q.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sun, 23 Mar 2025 02:34:54 +0100 (CET) Injection-Info: dont-email.me; posting-host="a15946f919c03f5587cb1d54f3992682"; logging-data="1227991"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ZIyXKYXgfzZzdbYFdMnUi" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:PLCXrZNZHQZQDVUww20kLiv2jlo= Content-Language: en-GB In-Reply-To: <871puoag2q.fsf@nosuchdomain.example.com> Bytes: 10748 On 22/03/2025 21:52, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 22/03/2025 03:50, Keith Thompson wrote: >>> bart <bc@freeuk.com> writes: >>>> On 21/03/2025 19:04, Keith Thompson wrote: >>>>> bart <bc@freeuk.com> writes: > [...] >>>>>> I think your response clarifies matters. Nobody cares, even as >>>>>> compilers grind to a halt under all preprocessing. >>>>> If compilers ground to a halt, I would certainly care. They don't. >>>> >>>> 50 modules each including GTK.h say, which was 0.33Mloc across 500 >>>> headers (so reading 16Mloc and 25,000 headers in total when all are >>>> compiled) would not impact your builds at all? OK. >>> First you talked about compilers grinding to a halt, then you talked >>> about headers not impacting builds at all. Those goalposts of yours >>> move *fast*. >> >> You missed the "?". > > No, I didn't. You insinuated that I had implied that large headers > would not impact builds. You phrased it as if you were questioning > something I had said. I don't care to debate this specific issue > further, but please be mmore careful. > >>> For the record, as you can see above, I did not say that builds would >>> not be impacted. Do not put words into my mouth again. >> >> Let me ask it again: so ploughing through a third of a million lines >> of code across hundreds of #includes, even at the faster throughput >> compared with compiling code, for a module of a few hundred lines, >> will have little impact? >> >> How about a project with 50 or 100 modules, each using that big >> header, that needs to be built from scratch? > > I don't know. I haven't taken the time to measure the impact, > and if I did there wouldn't be much I could do about it. It hasn't > particularly inconvenienced me. > > Most of the builds I do from source are straightforward. The general > pattern is roughly "configure;make;sudo make install". I have > a wrapper script that does that, figures out what arguments to > pass, adds some extra options, and so forth. I'm aware configures > scripts can be very large (the one for coreutils close to 95,000 > lines), but I really don't care or see why I should. It works. > Building coreutils and installing 9.6 on my system took about 5 > minutes, during which I was able to go off and do other things. It's strange: in one part of the computing world, the speed of building software is a very big deal. All sorts of efforts are going on to deal with it. Compilation speed for developers is always an issue. There is a general movement away from LLVM-based backends /because/ it is so slow. And yet in another part (namely comp.lang.c) it appears to be a total non-issue! Maybe people are just so inured to lengthy build-times that they think it is quite normal. Or the slowness is hidden behind clever makefiles that do their utmost to avoid compiling as much as possible. Or they just throw extra resources (fast machines and lots of cores) to mitigate it. > Could the whole thing be streamlined? Could a new version of the > autotools be developed that doesn't cater as much to obsolete systems > and generates smaller configure scripts? Would it substantially > improve build times? Quite possibly, but I'm not likely to be the > one to work about the details (unless someone wants to hire me to > look into it). Build-times is one part; ease of deployment is another. This is the the API for SDL2 as translated from C headers into my language: C:\sdl>dir sdl.m 8/07/2024 13:15 158,055 sdl.m Below is the API in its original C form. The above file is much easier to work with, copy, bundle, browse etc. I ask you, why would anybody care about all those separate headers? What purpose they do serve? (This SDL library is small compared with some! At least all the files are in one folder.) > [...] > >> So let me ask /this/ again: if such a library consisted of ONE compact >> header file, would it make the process simpler? Would it make >> compilation of multiple modules faster?) > > I don't know. But it seems likely that it would. It's hardly going to make it slower! When I have time, I will look into it myself. There is already a feature of my C compiler that can reduce a complex set of headers into one file [demonstrated above], but in the syntax of one of my two languages. That could be modified to generate C instead. (This is not just preprocessing; it needs to build a symbol table then work from that, taking care to preserve macro definitions, and suppressing system header symbols.) ------------------ c:\sdl\dir sdl2 14/06/2023 19:02 5,512 begin_code.h 14/06/2023 19:02 1,480 close_code.h 14/06/2023 19:02 8,084 SDL.h 14/06/2023 19:02 12,455 SDL_assert.h 14/06/2023 19:02 14,796 SDL_atomic.h 14/06/2023 19:02 59,694 SDL_audio.h 14/06/2023 19:02 3,205 SDL_bits.h 14/06/2023 19:02 9,047 SDL_blendmode.h 14/06/2023 19:02 4,307 SDL_clipboard.h 14/06/2023 19:02 8,894 SDL_config.h 14/06/2023 19:02 17,458 SDL_cpuinfo.h 14/06/2023 19:02 108,871 SDL_egl.h 14/06/2023 19:02 9,802 SDL_endian.h 14/06/2023 19:02 5,177 SDL_error.h 14/06/2023 19:02 47,284 SDL_events.h 14/06/2023 19:02 5,533 SDL_filesystem.h 14/06/2023 19:02 40,039 SDL_gamecontroller.h 14/06/2023 19:02 3,418 SDL_gesture.h 14/06/2023 19:02 3,146 SDL_guid.h 14/06/2023 19:02 43,268 SDL_haptic.h 14/06/2023 19:02 17,842 SDL_hidapi.h 14/06/2023 19:02 110,398 SDL_hints.h 14/06/2023 19:02 39,015 SDL_joystick.h 14/06/2023 19:02 11,044 SDL_keyboard.h 14/06/2023 19:02 15,629 SDL_keycode.h 14/06/2023 19:02 3,908 SDL_loadso.h 14/06/2023 19:02 3,812 SDL_locale.h 14/06/2023 19:02 11,684 SDL_log.h 14/06/2023 19:02 8,809 SDL_main.h 14/06/2023 19:02 6,693 SDL_messagebox.h 14/06/2023 19:02 3,380 SDL_metal.h 14/06/2023 19:02 2,845 SDL_misc.h 14/06/2023 19:02 17,087 SDL_mouse.h 14/06/2023 19:02 14,286 SDL_mutex.h 14/06/2023 19:02 1,155 SDL_name.h 14/06/2023 19:02 81,091 SDL_opengl.h 14/06/2023 19:02 1,254 SDL_opengles.h 14/06/2023 19:02 1,606 SDL_opengles2.h 14/06/2023 19:02 42,938 SDL_opengles2_gl2.h 14/06/2023 19:02 241,221 SDL_opengles2_gl2ext.h 14/06/2023 19:02 646 SDL_opengles2_gl2platform.h 14/06/2023 19:02 11,131 SDL_opengles2_khrplatform.h 14/06/2023 19:02 863,870 SDL_opengl_glext.h 14/06/2023 19:02 24,522 SDL_pixels.h 28/07/2024 12:43 6,746 SDL_platform.h 14/06/2023 19:02 3,199 SDL_power.h 14/06/2023 19:02 2,106 SDL_quit.h 14/06/2023 19:02 12,860 SDL_rect.h 14/06/2023 19:02 73,762 SDL_render.h 14/06/2023 19:02 243 SDL_revision.h 14/06/2023 19:02 28,101 SDL_rwops.h 14/06/2023 19:02 16,929 SDL_scancode.h 14/06/2023 19:02 10,265 SDL_sensor.h 14/06/2023 19:02 5,904 SDL_shape.h 14/06/2023 19:02 29,523 SDL_stdinc.h 14/06/2023 19:02 36,798 SDL_surface.h 14/06/2023 19:02 20,772 SDL_system.h 14/06/2023 19:02 11,506 SDL_syswm.h 14/06/2023 19:02 2,000 SDL_test.h 14/06/2023 19:02 3,235 SDL_test_assert.h 14/06/2023 19:02 6,872 SDL_test_common.h 14/06/2023 19:02 2,163 SDL_test_compare.h 14/06/2023 19:02 3,385 SDL_test_crc32.h ========== REMAINDER OF ARTICLE TRUNCATED ==========