Re: question about linker

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.