Re: question about linker

On 04/12/2024 22:31, Bart wrote:

On 04/12/2024 20:55, David Brown wrote:

On 04/12/2024 16:09, Bart wrote:

 

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

>
Buy a better keyboard.  Saving typing is a pathetic excuse.

 How does a better keyboard make this less cluttery:
     std::cout << xxx::X << yyy::Y << std::endl
 Compare with:
     cout << X << Y endl
 

Maybe a better keyboard would stop you from complaining about the horrors of having to press the shift key occasionally, or otherwise having to type more than an absolute minimum number of symbols.
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.
Avoiding or reducing clutter, on the other hand, is often a good thing - as long as it does not reduce the important information shown to the reader.
Thus in C++ you have "using" clauses that let you reduce the need for namespaces in the bits of code where you, the programmer, decide that omitting the namespace makes the code clearer.  It's an active choice. That's a good thing.  (C++ has many other ways to abbreviate code and hide detail that would otherwise obscure the code - such as "using" aliases for complex types, "auto", and references.)
C++ also has "argument-dependent lookup" - basically, that sees that the argument to the "<<" operator above is in std::, so it automatically looks for an appropriate "<<" operator in std:: to avoid having to write "std::cout std::<< x".  That does /not/ mean that the operator has been pulled into the local namespace - it means the other namespace has been searched because you've already given that namespace (in the argument).
Clearly I can only speak for my own opinion, but I don't want the /language/ to decide that all my symbols will be jumbled into one pile. If I have made namespaces, I have done so for a reason - I want to keep them somewhat separated and structured.  I might /choose/ to hide some of that structure in a piece of code if it makes things clearer, but I don't want the language to do that by default!

 

That seems to be something akin to C++ classes or structs with static methods.  But I'm not sure, and certainly not sure how it is relevant.

 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".  You designed the language for one person - you.  It would be extraordinary if it did not work the way /you/ expect!
Real programming languages involve a great many people if they are to evolve beyond a tiny niche.  That way they are influenced by lots of opinions, experiences, desires, and use-cases way beyond what any one person could ever have.  Real languages are always compromises - they are rarely "perfect" in anyone's views, but they are good enough in the view of many people.
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 complain about if they thought there were better ways to do it, and now millions of people use on a regular basis.  C++ namespaces work the way those millions of C++ programmers expect - because that's the way they work.  This does not necessarily mean that C++ namespaces work the way they /want/ - that's a very different question.  But of all the things people find difficult, and all the things people complain about (and there are many such things - no one has ever accused C++ of being a "perfect" language), the way namespaces work is simply not an issue.
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.

 Compare for example how filenames are resolved in a file system, when both absolute and relative paths are missing. Sometimes it will look in a list of special places (eg. using Windows' PATH variable) if not found locally.

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 is how file lookup would appear with your scheme.
With the way C++ namespaces work, it is pretty much exactly like people expect from a filesystem - normally unqualified names are from the current scope (like files from the current directory), and if you want names from a different namespace you qualify it (like specifying the directory explicitly for a file).  And for situations where you find it convenient to have a shortcut, C++ provides these (just as filesystems provide features user-level like symbolic links and a few common shortcuts like PATH).

 You don't agree with my choices, OK.

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.  Again, since you seem to forget this, I don't in any way think all your design choices are bad.  I have tried to explain /why/ I think this particular choice is bad, and how better alternatives could work.

 

Of course tcc won't work - I work with embedded systems, and as I have said countless times, your little tools don't target the devices I use.

 In my hardware days I built boards with embedded processors too.
 

So presumably you understand the concept of using a compiler that generates code for the actual target you want?  It should therefore not be a surprise that tcc would be useless to me.

I programmed them with my 'toy' language. Sometimes I didn't have have a compiler, so a couple of times I wrote an assembler for the device. The assembler (obviously, you will consider that a toy) was written in my toy language. (One was for 80188, the other was 8035 or 8051.)
 

OK.

My point is that 'toy' implementations /could/ work just as well, and here I was able to get working prototypes. (At least, until my boss had some new ideas and I moved on to something else.)
 

No, toy implementations could /not/ work "just as well" as good tools. They may be able to work well enough in limited situations.  They may be all you've got, or all you can afford, or there may be other overriding factors.  I've used weak tools when good ones were ruled out - but when I have the choice of good tools or poor ones, I choose good tools.  For simple little programs, it can make sense to pick the nearest tool - something easy and convenient that you are used to.  For a serious project - perhaps many man-months of work spread over a year and supported for a decade or more - you start by looking for the right tools for the task.  You don't use toys.
Except for developers working on massive code bases (like Scott), developer's computers have effectively unlimited space and unlimited computer power.  But the target systems usually do not.  This applies for software that will run on PC's, but especially for small embedded systems.  A compiler that generates twice as efficient code means I can use a cheaper microcontroller with half the flash and half the speed, using half the battery power and emitting half the EMI interference.  Or it can run a motor at twice the speed, or half the error ranges.
Optimisation in the compiler also means I can write clearer source code, knowing that the compiler will generate good results.  I've worked with tools where I needed to "manually optimise" code to get good results - use pointer arithmetic instead of arrays, shifts and adds instead of multiplies, function-like macros instead of inline functions, and so on.   It's harder work, uglier, less maintainable, and more error-prone.
And of course I would much rather find potential problems as soon as possible using static error checking, rather than later on during testing.
Your compiler and tcc don't reach ankle-level to gcc, clang or even MSVC for real work.  If they actually did work "just as well", and were much faster and simpler, then I'd use them.  (I'd still use make - no sane developer runs compilers manually for real work.)

 

I /need/ good optimisations - it's not an option, it's a requirement to get fast enough code for the end system to work.  So your toys would not be usable even if they supported the right target.

 And I did without an optimising compiler for 20 years. Not that C compilers were that much better for a lot of that period, of 82-02.
 

That's like some American boosting us how the USA got to the moon using imperial measurements so they don't need metric.  You managed /despite/ crippling yourself and your workflow, not because of it.  (I do understand that good tools were hard to get in those old days - but not for the last 20 years.)

   I use C++ as well as

C - your toys don't support that.  I use C17 (and will move to C23 when my tools support it) - tcc supports only up to partial C99 support, and $DEITY only knows what partial C standard your compiler handles.

 My C compiler is for my personal use. It will build only a tiny fraction of existing code, but will compile 100% of the code I write, or generate.
 So I'm not asking people to use it. But it shows what is possible.
 

It doesn't show anything useful is possible.  No one else wants to compile the limited subset of C that you want, nor do they want a C compiler written in some weird private language.  Some other people want to use or write small C compilers for a variety of reasons - your compiler does nothing for them.  (And their compilers probably do nothing for you.)  tcc at least tries to be useful to a wider range of users, and has some niche uses.
There's nothing wrong with writing your own C compiler - or partial C compiler.  If you find it useful, great.  If you enjoyed writing it, great.  Even if it is useless, it is still a sizeable achievement.  I have always said as much.
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.  Your tools are not better in any way that is meaningful to anyone else - even if they are ideal for /your/ use.