Re: question about linker

On 03/12/2024 19:42, Bart wrote:

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?

code the reading is important order people to.
Or, if you prefer,
Order is important to people reading the code.
The compiler spends milliseconds reading the code.  Programmers spend hours, days, or more reading the code.  It's not particularly important if the language requires a particular order or not, except in how it helps or hinders the programmer in their order of the code.  And it is certainly the case that different programmers will prefer different ways to order and arrange their code - but that does not stop it being important.  When you write code, write it for human readers - other people, including your future self.  If you like bottom-up ordering, fine.  If you like top-down ordering, fine.  If you like grouping functions and data in other ways, fine.  If you like a dog's breakfast, not so fine.

 

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.
 

Yes, I am making assumptions - I am assuming that what you write about your language is true.  I know that is far from a valid assumption when you write about C, but for your language, I've nothing else to go on.
I've already made it clear what I think is wrong about your solution - the jumbling of namespaces.  (And /please/ don't harp on about C's system again - the fact that C does not have a good way of handling namespaces does not suddenly make /your/ version good.)

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;

(You mean "using namespace A;".  It's no problem that you don't know the right syntax for C++, but I'm correcting it in case you want to try anything on godbolt.org.)
Yes, C++ /allows/ you to do that - if you explicitly choose to do so for a particular namespace.  Thus if you are going to use identifiers from a namespace often, and you are confident it will not lead to conflicts, then you can do so.  C++ "using namespace A;" is commonly used in a few circumstances:
1. At file scope to pull in a small namespace that you use extensively throughout the code in the file.
2. For things like "using std;" at file scope for quick and dirty programs - test programs, or code written by lazy programmers, to the annoyance of anyone later dealing with the code.
3. In block scope within a function that makes a lot of use of the namespace.  Within the function, you have far tighter control about what identifiers are used there so the code can remain clear.
4. For pulling in things like user-defined literals that would look really ugly with explicit namespace qualifiers.  These will usually be within a small block scope.
Having every module in a program automatically pull in every exported identifier from every other module in the program is not structured or modular programming - it is anarchy.

 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?
 

(Again - you mean either "using namespace A;" or "using A::F;".)
You get an error if you try to use "F", as it is ambiguous.  (Defining a new local function F is also an error even if F is never called.)

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.

I'm sorry, I thought you meant if a sane C programmer wrote good code but accidentally had conflicting types.  C is not as tolerant of idiots as some languages.

 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.
 

If you are a fool, you should probably avoid programming entirely.
Languages and tools should try to be accident-proof, not fool-proof.