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: Thu, 5 Dec 2024 15:29:10 +0000
Organization: A noiseless patient Spider
Lines: 173
Message-ID: <visgs7$1mgdb$1@dont-email.me>
References: <vi54e9$3ie0o$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>
 <viprao$umjj$1@dont-email.me> <viqfk9$13esp$1@dont-email.me>
 <viqhmn$131h8$3@dont-email.me> <visbmp$1ks59$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 05 Dec 2024 16:29:11 +0100 (CET)
Injection-Info: dont-email.me; posting-host="12866f4cee3d02926546f0c9d8eee755";
	logging-data="1786283"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Lt48M+KHCRwDKmKa9Z+IF"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:xqX/MWzeYmgiSFMxR3LTwxQMFtI=
In-Reply-To: <visbmp$1ks59$1@dont-email.me>
Content-Language: en-GB
Bytes: 8753

On 05/12/2024 14:00, David Brown wrote:
> On 04/12/2024 22:31, Bart wrote:

> And while you are at it, buy a better screen.  You were apparently 
> unable to read the bit where I said that /saving typing/ is a pathetic 
> excuse.

I can't type. It's not a bad excuse at all. I have also suffered from 
joint problems. (In the 1980s I was sometimes typing while wearing 
woolen gloves to lessen the impact. I haven't needed to now; maybe I've 
slowed down, but I do take more care.)

>> You said my namespaces were jumbled. They generally work as people 
>> expect, other than some different rules on name resolution.
> 
> No, they work as /you/ expect.  Not "people".

The concept is so simple that is not much about it for anyone to tweak.

A qualified name looks like this (this also applies to a single identifer):

   A.B.C

'A' is a top-level name. It is this that the name-resolution in a 
language needs to identify.

Presumably, in your C and C++ languages, all possible top-level names 
must be directly visible. Only in C++ with 'using namespace' does it 
allow a search for names not directly visible, by looking also in 
certain places.

This is where the rules diverge a little from what I do. Given 'CHUMMY' 
modules X, Y, Z (which I deliberately choose), then each effectively 
includes 'using namespace' for each of the other two modules.

I also have a different rule when there is clash between the contents of 
a 'using' namespace, and the set of directly visible names. As I say 
below, I consider the former to be in an outer scope.

The basics are more or less the same; some details differ. You can't say 
that C++ has the final word on it just because that's the committee 
choice it made, and every other approach must be wrong.

So my approach is a little more informal, and more convenient. I could 
have gone another way so that instead of writing this:

    pcl_start()
    pcl_end()

which is allowed instead of full qualifers which would be this:

   pcl.pcl_start()
   pcl.pcl_end()

I could use your strict approach. Then I'd use a different naming 
scheme, so that it looks like this:

   pcl.start()
   pcl.end()

This is not that different from the above! But I'd be uneasy about using 
non-prefixed names within that library. (For one thing, 'start' is a 
special function name; and 'end' is a keyword! There'd be other clashes.)

In short, you are just quibbling. I probably implemented 90% of what C++ 
has, you're trying to make out it's utterly different and unsuitable.

BTW, once 'A' has been resolved, then .B and .C generally are 
unambigious in my static language (and may need runtime checks in my 
dynamic one, if A is a variable rather then a module or type).

In C++ however, I suspect that what .B and .C mean may be subject to 
overloads, inheritance, and who knows what else.


>  You designed the language 
> for one person - you.  It would be extraordinary if it did not work the 
> way /you/ expect!

Yep. And yet, it is not some obscure, exotic monstrosity. It's not that 
different from most others, and it's not that hard to understand.

>  That way they are influenced by lots of 
> opinions, experiences, desires, and use-cases way beyond what any one 
> person could ever have.

A shame it didn't work for C!

> So the way namespaces work in C++ is something that - by my rough 
> finger-in-the-air estimates - dozens of people were involved in forming 
> the plans, hundreds of people would have had a chance to comment and 

Yeah. Design-by-committee. Just about every feature of C++ is a dog's 
dinner of overblown, over-complex features. C++ doesn't do 'simple'. 
(Look at the 'byte' type for example; it's not just a name for 'u8'!)

> That suggests that the ratio of people who expect identifiers from 
> namespaces to require namespace qualification unless you /explicitly/ 
> request importing them into the current scope, compared to the people 
> who expect namespaces to default to a jumble and overwhelm the current 
> scope, is of the order of millions to one.

They're not imported into the current scope, but an outer scope. 
Anything with the same name in the current scope will shadow those imports.

C and C++ both have block scopes, yes? So the potential is there for 
nested scopes dozens of levels deep.

> Yes - /sometimes/ file lookup uses some kind of path.  That happens for 
> specific cases, using explicitly set path lists.  Who would be happy 
> with an OS that when they tried to open a non-existent file "test.txt" 
> from their current directory in an editor, the system searched the 
> entire filesystem and all attached disks?  When you use the command 
> "tcc", would you be happy with a random choice - or error message - 
> because someone else put a different program called "tcc.exe" on a 
> network drive somewhere?

That's exactly how Windows works. I think Linux works like that too: 
since tcc.exe is not a local file, and it doesn't use a path, it uses 
special rules to locate it. Somebody could mess about with those rules.

So, why don't you always have to type:

   /usr/bin/tcc.0.9.28/tcc             # or whatever

instead of just 'tcc'?

> No, I don't agree with them.  Yes, it is your choice for your language.
> 
> But you choose to talk about your language - so I can tell you why I 
> think they are not good design choices.

My design is to allow default 'using namespace'; see above.

That's ... pretty much it.

> Your compiler and tcc don't reach ankle-level to gcc, clang or even MSVC

That's good.

I once had to build a garden gate for my house. I decided to make my 
own, and ended up with a 6' wooden gate which was exactly what I needed.

If LLVM made gates, theirs would have been 9 miles high. A little 
unwieldy, and probably a hazard for air traffic.

> It doesn't show anything useful is possible.  No one else wants to 
> compile the limited subset of C that you want,

That's not true. Thiago Adams would find it useful for one. Obviously I do.

Anyone using C an intermediate language would do so. As would anyone 
writing C up to C99.

> nor do they want a C 
> compiler written in some weird private language. 

Weird? There's a lot more weirdness in C!

> But it is not an alternative for other people.  It is not some kind of 
> proof that compilers - real compilers for real work - don't have to be 
> large.

I suspect your prefered compilers wouldn't even run on a Cray-1 
supercomputer, perhaps not even dozens of them.
========== REMAINDER OF ARTICLE TRUNCATED ==========