Sujet : Re: Suggested method for returning a string from a C program?
De : bc (at) *nospam* freeuk.com (bart)
Groupes : comp.lang.cDate : 25. Mar 2025, 15:58:28
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vrugaj$3ij4s$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
User-Agent : Mozilla Thunderbird
On 25/03/2025 11:29, Michael S wrote:
On Tue, 25 Mar 2025 08:40:34 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:
On Mon, 24 Mar 2025 18:20:02 +0000
bart <bc@freeuk.com> wibbled:
>
Fast compilers and also whole-program compilers open up lots of new
possibilities. But clearly you're quite happy being stuck in the
stone age.
>
The stone age is where they used one huge source file for a program.
>
Separate compilation process and modularization/# of source files are
not directly related.
When the speed (or size, or correctness) is paramount, separate
compilation is inevitably inferior to whole-program compilation.
If people still use separate compilation, it does not happen because
it is good thing, but because compilers are too slow. Or, if we're
talking about Unix world, out of inertia.
In Windows world release builds of majority of C/C++ software is done
LTCG. Most developers do not even think about it, its a default. Even
in Linux world, projects that care about experience of their users,
like for example Firefox, use LTCG as a minimum, sometimes even going
for profile-guided whole program compilations.
So, what exactly is released to end-users? Where is the final linking done? If on the user's machine, will the necessary tools also be bundled?
The way I do it is illustrated below. M/MA/C/O represent individual source or object files. Groups like (C, C, C) represent the multiple files, perhaps in assorted locations, of the original source code.
A typical C project is built like this, with -> representing compiling, linking etc:
(C, C, C) -> (O, O, O) -> (EXE)
For project to be locally built (compiled, optimised and linked) at a user-site, then (C, C, C) must be distributed (plus the usual junk in addition to the compiler and linker)
My language works like this on my home machine:
(M, M, M) -> (EXE)
But if I wanted people to build from source on their own machine (and assuming they had my compiler), the process would be:
(M, M, M) -> (MA) -> (EXE)
MA is a one file source amalgamation which is what is provided. (So the user needs two files, that, and the compiler.)
However nobody has my compiler, as such binaries are not trusted, so the process is often this instead:
(M, M, M) -> (C) -> (O) -> (EXE)
I provide the one-file C rendering. The process from that point on depends on their C compiler, but this is typical, even if O files are normally hidden, if a discrete linker is used.
So whole-program-optimisation is useful by-product.
(But it includes only the code I write; not libraries. Presumably LTCG works with part-compiled libraries that are to be statically linked? I only work with DLLs. However I don't see LTCG being practical with giant libraries like GTK.)
Anyway it is this intermediate single C file that is causing many people here to have kittens and to accuse me of not caring about modularisation.