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: question about linker
Date: Tue, 3 Dec 2024 18:42:47 +0000
Organization: A noiseless patient Spider
Lines: 139
Message-ID: <vinjf8$8jur$1@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me> <viaqh0$nm7q$1@dont-email.me>
 <877c8nt255.fsf@nosuchdomain.example.com> <viasv4$nm7q$2@dont-email.me>
 <vibr1l$vvjf$1@dont-email.me> <vic73f$1205f$1@dont-email.me>
 <20241129142810.00007920@yahoo.com> <vicfra$13nl4$1@dont-email.me>
 <20241129161517.000010b8@yahoo.com> <vicque$15ium$2@dont-email.me>
 <vid110$16hte$1@dont-email.me> <87mshhsrr0.fsf@nosuchdomain.example.com>
 <vidd2a$18k9j$1@dont-email.me> <8734j9sj0f.fsf@nosuchdomain.example.com>
 <vidnp3$1ovvm$2@paganini.bofh.team> <vihpjh$2hgg1$1@dont-email.me>
 <vihrh1$2hk5l$1@dont-email.me> <vii0jp$2jkd9$1@dont-email.me>
 <viifv8$2opi7$1@dont-email.me> <vik28b$390eg$1@dont-email.me>
 <vik8tc$3ang9$1@dont-email.me> <vikjff$3dgvc$1@dont-email.me>
 <viku00$3gamg$1@dont-email.me> <vil0qc$3fqqa$3@dont-email.me>
 <vil82t$3ie9o$2@dont-email.me> <vila9j$3j4dg$1@dont-email.me>
 <vin4su$49a6$1@dont-email.me> <vin95m$5da6$1@dont-email.me>
 <vinh3h$7ppb$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 03 Dec 2024 19:42:49 +0100 (CET)
Injection-Info: dont-email.me; posting-host="58051acb06834042f2b64be747d68961";
	logging-data="282587"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/fRhywqVOozf1fY0h3YyPz"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:GLA/RsSZZkMR0iv1BgCPuxMJsUs=
Content-Language: en-GB
In-Reply-To: <vinh3h$7ppb$1@dont-email.me>
Bytes: 6469

On 03/12/2024 18:02, David Brown wrote:
> On 03/12/2024 16:47, Bart wrote:
>> On 03/12/2024 14:34, David Brown wrote:
>>> On 02/12/2024 22:53, Bart wrote:
>>
>>>> So, how would you have organised the 16-module example I posted 
>>>> elsewhere? (Not a C project, these are 16 source files, so no 
>>>> headers etc.)
>>>>
>>>> Because two posters here have suggested my organisation is poor, but 
>>>> without knowing how big, small, or complex my projects are.
>>>
>>> No one (as far as I have noticed) have said that your organisation 
>>> /is/ poor - they have said it /sounds/ poor from the way you describe 
>>> it. The difference is very significant.
>>>
>>> For file organisation, I'd likely have all the modules in one 
>>> directory unless there is a particular reason to split them up.  I 
>>> would not have any non-project files in that directory.
>>>
>>> But the questions raised about your organisation was not a matter of 
>>> where you store your files, or how they are divided in directories. 
>>> It is about how you organise the code and split functionality between 
>>> files (or directories, for bigger projects).
>>>
>>> What you have described is modules that have far too much in one 
>>> file, modules with little or no structure as to where things are in 
>>> the file, 
>>
>> Because it doesn't really matter.

> 
> It really /does/ matter - regardless of what the language allows or does 
> not allow.

Why?

What possible difference can it make if functions are in the order F G H 
in the file or H G F?

(Of course, it might matter for the C language for those who can't be 
bothered to provide the forward references the language makes possible.

But I assume you have something else in mind. Note that lots of 
languages now allow out-of-order functions - allow a call to F before F 
is defined - so what you are complaining about here applies to those too.)



> If your language does not enforce ordering rules,

There ARE no ordering rules! That's what 'out-of-order' means.

(The only place where ordering might matter, is in the list of modules 
that describe the project. And that's only because of a feature where a 
special initialisation function in each module can be invoked 
automatically. The app may need those called in a certain order.)

> that gives 
> you more flexibility, but it does not relieve you of your responsibility 
> as a programmer of writing code in a logical and structured manner.

With forward declarations provided, then C provides exactly the same 
flexibility in function ordering.


>> In C, if you have 100 modules, but modules 23 and 87 need to share 
>> some variable or function, it can be visible to the other 98 too, or 
>> can clash with the same name thaty 17 and 26 want to share. Or with a 
>> name that module 72 forgot to make static.
> 
> C has a risk of name clashes - that's why I am a fan of namespaces 
> (proper ones, not your weird half-arsed solution).

What's wrong with my solution? You seem to be making assumptions about it.

All it does is allow you to write F() instead of A.F(). You can do the 
same thing in C++ (there it saves you writing A::), by doing this (AIUI):

   using A;

I could spend 30 minutes in providing an option so that it needs to be 
explicit like this, but I don't have a pressing need to do so.

BTW what happens in C++ when you do this:

   using A;
   using B;
   F();

and both A and B export (or make public) F? What happens if there is 
also a locally defined F?

>> Or module 49 exports variable 'abc' as int, but 53 imports it as 
>> 'char*', then fun and games follow. C has a lot worse problems!
> 
> That will be caught at link time, if not before

Is it?

   c:\cx>type a.c

    extern void F(void);

    int abc;

    int main(void) {
        abc=12345;
        F();
    }

   c:\cx>type b.c
    #include <stdio.h>

    extern char* abc;

    void F() {
        puts(abc);
    }

    c:\cx>gcc a.c b.c
    c:\cx>a
    ....

This crashes. This program is impossible to write in my language when 
both modules are part of the program.

Only when the two functions are in different binaries so that one 
program needs to work with a potentially incorrect declaration. Even 
then, generating a DLL can also export an interface file with the 
correct declarations.

Then it can only go wrong if one binary is updated and recompiled, but 
not the other. But this applies to any language.

So it's a lot more fool-proof.