Re: question about linker

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.  If your language does not enforce ordering rules, 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.

(My language allows out-of-order everything. So all module-scope variables could go at the end of the file, or file-scope variables at the end of the function! However I don't do that.
 But I really don't want to care about whether function F precedes G in the file, or follows it. Any more than I would care whether a file "F" is stored before or after file "G" in a directory! The ordering could be sorted in different ways for display; perhaps an editor could do the same. (I guess your IDE does that.)
 

little to no structure or control over which modules use facilities from which other modules, and completely random inter-module dependencies which can happily be circular.

 They can be circular when it makes sense. They are after all part of the same program!
 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).  But if only modules 23 and 87 need access to the identifiers exported by module 42, then only those modules (and 42 itself) should include header 42.  Module 68 will not include it, and can happily re-use the same identifiers as static identifiers or local variables.  And if the writer of module 72 forgot to make a function static, ban them from the coffee machine until they have learned to use their tools correctly.
You don't get to say that because it is possible to have certain problems in large C programs, anarchy should reign - especially not when you are making your own language and can get it right!

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 - unless you have crappy tools or an ignorant programmer who doesn't know how to use them.