Deutsch   English   Français   Italiano  
<viprao$umjj$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

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: Wed, 4 Dec 2024 15:09:12 +0000
Organization: A noiseless patient Spider
Lines: 182
Message-ID: <viprao$umjj$1@dont-email.me>
References: <vi54e9$3ie0o$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> <vinjf8$8jur$1@dont-email.me>
 <vip5rf$p44n$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 04 Dec 2024 16:09:12 +0100 (CET)
Injection-Info: dont-email.me; posting-host="69d0651bc57abb644b06a60528b27c1d";
	logging-data="1006195"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+d92GilS/UgHT1xEmzAxNU"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:KsPm89LVb9UceiTeT9YIrI7BRtk=
Content-Language: en-GB
In-Reply-To: <vip5rf$p44n$1@dont-email.me>
Bytes: 8410

On 04/12/2024 09:02, David Brown wrote:
> On 03/12/2024 19:42, Bart wrote:

>>> 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.

You've lost me.

A language source file isn't a story that needs to be consumed 
sequentially. It will be a collection of functions that will have some 
arbitrary call-pattern at runtime, perhaps different each time.

So the static ordering is irrelevant. If you're looking at F, which 
calls G, and you want to look at G, then G is not always going to be 
immediately before F! It might be at any point before, so it might 
equally be at any point after. Or it could be located at anywhere in the 
100s of modules that comprise the project.

In any case, you'd probably just click on G and it will take you there.

To put in another way, I've never noticed any particular pattern in 
function ordering of any open source project.

This sounds like something peculiar to you.


>  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 

And here I've lost track of what this particular complaint about me is 
about. But it looks like it would apply to the majority of the world's 
programmers.

Perhaps functions should be in alphabetic order?


> 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:

It's used to avoid cluttering code with ugly xxx:: qualifiers, and save 
some typing at the same time. That's pretty much it.

To that end, C++ and my language achieve the same thing. I just decided 
to make 'using namespace xxx' the default, and haven't got around to 
making it optional. (In an early version, I did need such a directive.)

(However it most likely differs from C++ in what it calls 'namespaces'.

My remarks have been about the namespace that is created by a module.

I understand that C++ namespaces can be created in other ways, like 
classes. I sort of have that too, but rarely use the feature:

  record foo =
      proc F = println "FOO/F" end
  end

  record bar =
      proc F = println "BAR/F" end
  end

  proc F = println "MAIN/F" end

  proc main =
      foo.F()
      bar.F()
      F()
  end

Here, I don't need to create instances of foo and bar; they serve to 
encapsulate any kinds of named entities.)



> 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.

In the 'subprogram'. The structure is there.

 > in every exported identifier

Yes, every EXPORTED identifier. An exporting module doesn't know which 
modules are going to access that identifier, and it doesn't have any 
control over that (I don't know of any scheme allows that; maybe you do?)

So it knows it could be used from anywhere that imports this module.

I decided to create a concept of a 'chummy' set of modules (the 
'subprogram') which freely see others exports, while not seeing the 
local entities which are kept private.

Much like people in a rooming house call each other by their first names.

> You get an error if you try to use "F", as it is ambiguous.

Same here.

>  (Defining a 
> new local function F is also an error even if F is never called.)

That I don't do, as it is the typical and expected behaviour when you 
have shadowing of names in an outer scope; generally it is not reported.

However, things can always be tweaked. I just find the model works fine 
for me.

>> 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.

>> So it's a lot more fool-proof.

> If you are a fool, you should probably avoid programming entirely.

Fuck you. Obviously you're going to shoot down whatever I say, trash 
whatever I have achieved, because .... I've really no idea.

Yesterday you tried to give the misleading impression that compiling a 
substantial 200Kloc project only took 1-3 seconds with gcc.

I gave some timings that showed gcc-O0 taking 50 times longer than tcc, 
and 150 times longer with -O2.

That is the real picture. Maybe your machine is faster than mine, but I 
doubt it is 100 times faster. (If you don't like my benchmark, then 
provide another in portable C.)
========== REMAINDER OF ARTICLE TRUNCATED ==========