Re: question about linker

On 29/11/2024 12:04, Bart wrote:

On 29/11/2024 07:38, David Brown wrote:

On 29/11/2024 00:05, Bart wrote:

On 28/11/2024 22:38, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

On 28/11/2024 19:58, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:
[...]

I think 'const' is confusing for similar reasons that VLAs can be both
confusing and awkward to implement.
>
That's because both really apply to /types/, not directly to variables.

Sure.  For example, given
      const int n = 42;
n is of type `const int`, and &n is of type `consts int*`.  Of course
that implies that n itself is const.

>
But that is a separate thing. Suppose T was an alias for 'const int'. Then:
>
   T x;           // defines a readonly variable (which probably needs
                  // initialising)
   T* y;          // defines a variable pointer
>
'const' is out of the picture.

>
You say T is an alias (what, a macro?) for 'const int', you show code
using T, and then you say "'const' is out of the picture".  If you have
a point, it escapes me.

>
Well, can you see 'const' in my example? You can't tell x is readonly by only looking at this.
>
>

Yes, and you seem determines to make it easier to get mixed up.

>
>
C doesn't require any help from me for confusing features. The OP said it was confusing and I tried to point out why it might be.
>
Obviously you as C expert will never be confused. But there are lots of less expert users of the language.
>
I've just several minutes trying to figure why all these assignments are invalid:
>
     typedef int* T;
>
     int  const x;

>
That one is really simple - clearly "x" is declared "const", and so you can't assign to it later.
>

     T    const y;

>
That one is equally simple - clearly "y" is declared "const", and so you can't assign to it later.
>
That shows exactly why it can be a good idea to use "typedef", even for relatively simple things such as adding a pointer or qualifiers to the type.  I would not normally make a typedef just for a pointer, or just to add a "const" qualifier, but if the final type is complicated, it can make things clearer.  Really, it's just like breaking a complicated expression into parts with extra local variables to name them.
>

     int* const z;
>

>
This one requires a little more thought, but it should be well within the capacity of any C programmer to see that "z" is declared "const".

 These are similar examples:
      int * const z1;
     int const * z2;
      z1=0;          // invalid
     z2=0;          // valid
 

Yes.  This is C course lesson 1 stuff.
The type here comes in two parts - the pointer, and the thing being pointed at (the "pointee", if that's a real word).  So there are two parts that could, independently, be qualified as "const" - thus it matters whether the "const" is before or after the asterisk.
I don't disagree that there are other ways to make a language syntax to specify types, or that some alternatives might be easier to follow than C (such as always left-to-right, or always right-to-left).
But cases like this are not hard, and it is not at all unreasonable to expect anyone who calls themselves a "C programmer" to handle those examples without a moment's thought.
And if you get it muddled, the chances are very high that the compiler will tell you when you try to compile the code (any compiler will complain about assigning to a const, not just ones with good static error checking).

  

     x=0;
     y=0;
     z=0;
>
because I thought would behave differently, with 'const' being the opposite side of '*' to the base-type.
>

>
The "const" in each case clearly applies to the type of the declared variable.
>

I forgot that here it would be the right-most 'const' that controls storage attributes of 'z'.

 Both 'const' in my new examples are the the right-most one! Yet one makes the immediate storage const and one doesn't. I guess then that it's the right-most possible 'const' if it were to be used. In my example,  that would follow the '*'.

You invented a rule (that the right-most "const" controls the variable), and it turned out to be wrong.  In hindsight, that should be totally obvious to you - if your rule had been true, there would be no way to specify a non-const pointer to const data, since the first "const" would also be the last one.
Instead, try to learn the rules of C, rather than making up incorrect rules and confusing yourself.

 

You will of course say that I'm the only person in the world who could make that mistake.
>

>
I certainly don't say you are the only person in the world who /could/ make that mistake.  But if we narrow it down to the C programmers who /would/ make such mistakes, you are in a much smaller group.
>
There are two types of C programmers - those who like to declare variables "const" on a regular basis, and those who rarely if ever do (reserving "const" for things like "const int *" pointers).  Those that declare const variables, initialise them at the time, and would not be trying to assign them later.  Those who don't have much use of const variables, would not be writing such code in the first place.
>
Basically, I'd only expect to see examples like that in the questions section of a beginner's book on C.  And I'd expect anyone who had read the preceding chapter to be able to answer it.

 My original point was trying to address why 'const' as used in C might be confusing. I was trying to compare how non-mutable variables are designated in other languages. There it's a keyword that is part of the declaration syntax, not the type syntax.
 

C makes "const" part of the type - it is a type qualifier.  It is also possible for a language to make "constness" an attribute of the variable but not of the type.  The C language makes the design decision that variables don't get extra attributes - qualifiers like "const" and "volatile" must therefore by part of the type.  That simplifies many things in the language.  (That design decision is independent of the syntax used to specify types - it would apply even if C had used, say, "const * (const int)" to specify "const pointer to type const int".)
Some languages do have declaration keywords that determine the constness of the declared variable, yes.  I don't know if the constness of the variable is part of the variable's type or an extra attribute or characteristic - that will depend on the language in question.  If the language allows you to specify arbitrarily complex pointer types and their constness, you'd still need something equivalent to "const" and "mutable" in multiple places - the initial keyword only covers the outermost case.
But C does not have any keywords involved in declaring variables.  So having two keywords to distinguish "const" makes no sense for C.  It would also not work well, given that C has three type qualifiers - "const", "volatile" and "_Atomic".  ("restrict" is syntactically a type qualifier, but is a bit different and best ignored here.)  Would you want to have other keywords for declaring "volatile", "volatile const", and _Atomic combinations?
Having said that, I think it is nice for a language to be a little bit more verbose and explicit than C, and I would prefer if there were keywords for declaring and defining variables (and functions).  Having separate keywords for defining const and non-const variables would be a complication to the language and rules, since it would have to come in addition to supporting these traits in pointed-to types, but it would be convenient in use - most variables, after all, are not pointers.

I suggested that C is confusing because 'const' looks as though it's like the former, but it's part of the latter. Which also means you can have multiple 'const' in a declaration (putting asided repeated 'consts').
 

You find C confusing because you are determined to find it confusing, and are willing to invent incorrect "rules" to boost your confusion.
Yes, it is possible to write types in C that are hard to comprehend.  It is, however, easy to avoid doing so in C - just as it is possible to write code that is hard to comprehend in any other language.

So objectively, it IS more complicated than elsewhere with more scope for getting it wrong.
 

There is nothing objective in what you have written.  We all understand your /subjective/ opinion.  Some people (occasionally even me) may agree with some of your opinions - that does not make them objective.

But of course, this group being what it is, people have to turn it round to make it about me: I'm deliberately trying to show confusing examples.

I would be disappointed if those were the most "confusing" examples you could come up with!

Or I'm to thick to understand how const works.
 

I don't think you are too "thick" here.  I think you are applying considerable intelligence and thought into making it /appear/ that C's syntax is difficult.  You need only use a tiny fraction of that intelligence to understand the C rules for type specifications well enough to handle "int * const z1" without effort.  (We all agree that long and complex multi-part types are harder to follow.)
If you ran a business selling tools for your own languages, this would all make sense.  Since you don't do that, the biggest source of confusion here is what motivation you have for your campaign of invented FUD here.