• Addition of nocode keyword

    From Rick C. Hodgin@21:1/5 to Keith Thompson on Wed Oct 30 09:44:33 2019
    On Wednesday, October 30, 2019 at 11:41:13 AM UTC-4, Keith Thompson wrote:
    Rick, that's not how this works. David can post whatever he likes.

    Of course he can. My request remains. It's on David now to
    honor that request or not.

    [obvious explanation snipped]

    --
    Rick C. Hodgin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Kuyper@21:1/5 to Nick Bowler on Wed Oct 30 13:30:14 2019
    On 10/30/19 12:47 PM, Nick Bowler wrote:
    On Wed, 30 Oct 2019 08:12:24 -0700, jameskuyper wrote:
    "auto" has been a keyword for longer than C has been a language. It is,
    in fact, a carry over from one of C's predecessor languages (I'm not
    sure whether it was introduced in B or in BCPL). It actually made more
    sense in the predecessor language. In C, the only places where you're
    allowed to use "auto" are places where automatic storage duration is the
    default, so leaving out "auto" would give the same result as using it.
    As a result, C code almost never uses "auto". Something about it's
    predecessor language was different (I'm not sure what) that made "auto"
    a reasonable thing to use in that language.

    In B, local variables are declared like this:

    auto x;

    This syntax was permitted and works basically the same way in the original
    C standards. In this specific case, removing 'auto' in fact changes the meaning of the declaration (so in C90 it was not the case, in general,
    that removing "auto" would give the same result as using it).

    C99 and later standards completely removed this particular declaration
    style from the language; all remaining uses of the auto keyword are truly redundant. However most modern C compilers still support this syntax
    (with the required diagnostic message) even when they implement recent standards.


    I knew that, and forgot about it, and should have modified my
    explanation to accommodate those facts. However, even in C90, that usage
    of "auto" could equally well have been handled by typing "int x;", which involves (very marginally) less typing.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Rick C. Hodgin on Wed Oct 30 18:30:04 2019
    On 30/10/2019 17:44, Rick C. Hodgin wrote:
    On Wednesday, October 30, 2019 at 11:41:13 AM UTC-4, Keith Thompson wrote:
    Rick, that's not how this works. David can post whatever he likes.

    Of course he can. My request remains. It's on David now to
    honor that request or not.


    I don't want to get more repetitively off-topic, but the point - as
    Keith explained - is that this is a public newsgroup. Anything a person
    posts here may be read and quoted by anyone else, and anyone can reply
    to those posts. Replies in a newsgroup are not personal - they are for everyone who accesses the group or its archives, now and in the future.
    Posts may be more or less targeted at a particular poster, but they are
    always for the whole group.

    If you want to take the advice or use the information in posts I make,
    great. If you want to ignore them, that's your choice. When people
    make informative posts to newsgroups, it is usually in the hope that it
    will be of use or interest to others as well. If I had wanted to make a personal reply to you, Rick, I'd have sent an email.

    No, I will not honour any request to avoid following up to Usenet posts
    just because you made the post. That is not how Usenet works. I will
    happily honour a request not to make direct contact or email you -
    because that is about personal contact. But Usenet is public, and you
    don't get to impose gag orders on anyone.

    And I really hope that is the end of this particular silliness.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Nick Bowler on Wed Oct 30 18:37:32 2019
    On 30/10/2019 17:47, Nick Bowler wrote:
    On Wed, 30 Oct 2019 08:12:24 -0700, jameskuyper wrote:
    "auto" has been a keyword for longer than C has been a language. It is,
    in fact, a carry over from one of C's predecessor languages (I'm not
    sure whether it was introduced in B or in BCPL). It actually made more
    sense in the predecessor language. In C, the only places where you're
    allowed to use "auto" are places where automatic storage duration is the
    default, so leaving out "auto" would give the same result as using it.
    As a result, C code almost never uses "auto". Something about it's
    predecessor language was different (I'm not sure what) that made "auto"
    a reasonable thing to use in that language.

    In B, local variables are declared like this:

    auto x;

    This syntax was permitted and works basically the same way in the original
    C standards. In this specific case, removing 'auto' in fact changes the meaning of the declaration (so in C90 it was not the case, in general,
    that removing "auto" would give the same result as using it).

    I think that was only because of the "implicit int". In older C,
    "implicit int" meant that "auto x;" had the same meaning as "auto int
    x;". Removing the "auto" from that, you'd get "int x;", which would
    have exactly the same meaning (in contexts where "auto int x;" is allowed).

    I haven't used B (or BCPL) - could it be that they did not have
    different types, and thus no equivalent of "int x;" ?


    C99 and later standards completely removed this particular declaration
    style from the language; all remaining uses of the auto keyword are truly redundant. However most modern C compilers still support this syntax
    (with the required diagnostic message) even when they implement recent standards.


    Once "implicit int" was removed from the language, you could no longer
    write "auto x;" - you had to write "auto int x;", "register int x;" or
    just "int x;" (with the auto implied) for a non-static local variable.
    As there is no benefit in including the "auto", it is rarely seen. But compilers /must/ still support "auto int x;" if they try to be
    conforming, as it is still allowed even in modern standards. And many
    still allow "auto x;" (with implicit int) when compiling in lax modes,
    for support for older code.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nick Bowler@21:1/5 to David Brown on Wed Oct 30 18:34:39 2019
    On Wed, 30 Oct 2019 18:37:32 +0100, David Brown wrote:
    On 30/10/2019 17:47, Nick Bowler wrote:
    In B, local variables are declared like this:

    auto x;

    This syntax was permitted and works basically the same way in the
    original C standards. In this specific case, removing 'auto' in fact
    changes the meaning of the declaration (so in C90 it was not the case,
    in general, that removing "auto" would give the same result as using
    it).

    I think that was only because of the "implicit int". In older C,
    "implicit int" meant that "auto x;" had the same meaning as "auto int
    x;". Removing the "auto" from that, you'd get "int x;", which would
    have exactly the same meaning (in contexts where "auto int x;" is
    allowed).

    This is all true, but as soon as you add 'int' to the declaration the
    syntax is no longer compatible with B. This is probably not a problem
    because I doubt there were many programmers who cared about maintaining
    B-like syntax in 1999.

    I haven't used B (or BCPL) - could it be that they did not have
    different types, and thus no equivalent of "int x;" ?

    B has no data types (or depending how you look at it, only one type).

    Imagine a variant of C where the only object type you are allowed to use
    is 'int', and that you can use an 'int' value in any context where you
    might want to use a pointer to an int. Require 'auto' when declaring
    local variables, then delete all the 'int' keywords and you'll have a
    pretty good idea of what B programs look like.

    And if you write a program under this variant, it is quite likely that
    it will be successfully translated by a modern C compiler (with warnings), provided that conversions from int * to int do not lose information (this
    is a requirement since B has no pointer types).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to guinness.tony@gmail.com on Thu Oct 31 00:19:03 2019
    guinness.tony@gmail.com writes:

    On Tuesday, 29 October 2019 20:31:52 UTC, Rick C. Hodgin wrote:
    <cut>
    New keywords have been added to C with each revision. At some
    point the keyword "auto" did not exist. int auto = 0; would've
    been valid. It's not any more.

    At what point did C not have the keyword 'auto'?

    It's present even in the earliest C manual I can find: https://www.bell-labs.com/usr/dmr/www/cman.pdf

    It's also in C's predecessor B. I think it's safe to say it has always
    been in C, even before C was publicly described.

    --
    Ben.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rick C. Hodgin@21:1/5 to jameskuyper@alumni.caltech.edu on Wed Oct 30 21:29:21 2019
    On 10/30/2019 11:12 AM, jameskuyper@alumni.caltech.edu wrote:
    On Tuesday, October 29, 2019 at 7:36:49 PM UTC-4, Rick C. Hodgin wrote:
    Exactly when was "auto" reserved by the C committee? That C code
    I wrote that's been compiling all these years since the 1980s now
    breaks because they reserved the word auto in the 1990s? 2000s?
    2010s?

    What are you talking about? ...

    "auto" has been a keyword for longer than C has been a language. It is,
    in fact, a carry over from one of C's predecessor languages (I'm not
    sure whether it was introduced in B or in BCPL). It actually made more
    sense in the predecessor language. In C, the only places where you're
    allowed to use "auto" are places where automatic storage duration is the default, so leaving out "auto" would give the same result as using it.
    As a result, C code almost never uses "auto". Something about it's predecessor language was different (I'm not sure what) that made "auto"
    a reasonable thing to use in that language.

    I've never used it. I didn't even know it was a C language keyword
    until I was reading the C Standard the other day. After reading what
    it does I still don't see why it exists. I came across a website
    referencing it that reads:

    "In the language C auto is a keyword for specifying a storage
    duration. When you create an auto variable it has an 'automatic
    storage duration'. We call these objects 'local variables'. In
    C, all variables in functions are local by default. That’s why
    the keyword auto is hardly ever used."

    A wasted use of an otherwise desirable functionality as is seen in
    C++.

    This is what I'm talking about with the C committees being reaction-
    ary rather than visionary. They don't move in ways that make sense.
    They move trailing others who are moving in ways they think makes
    sense, effectively codifying what's seen in the real world.

    It should be more than that. The C committee should be steering.

    That's why C++ was able to give "auto" a new meaning, one that probably
    broke your code when you compiled it in C++.

    There was no code. It was a fictitious example conjured up to
    prove a point. It would work with any keyword that was later
    added to the language.

    It doesn't matter. I keep saying this, and it's hard for me to
    flatly and coldly turn my back on something or someone (it takes
    a real chain of events to make it happen), but I'm done with any
    attempt to improve C via the C Standard or such related.

    If you're done with it, why are you posting new suggestions to
    comp.std.c?

    I am done with it now after this go around. I had said previously
    I was done with it, but it's very difficult for me to hold rigid
    lines on things. I tend to soften over time. It takes a very
    special set of circumstances to push me to that point and keep me
    there.

    --
    Rick C. Hodgin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jameskuyper@alumni.caltech.edu@21:1/5 to Rick C. Hodgin on Thu Oct 31 08:37:05 2019
    On Wednesday, October 30, 2019 at 9:29:28 PM UTC-4, Rick C. Hodgin wrote:
    On 10/30/2019 11:12 AM, jameskuyper@alumni.caltech.edu wrote:
    On Tuesday, October 29, 2019 at 7:36:49 PM UTC-4, Rick C. Hodgin wrote:
    Exactly when was "auto" reserved by the C committee? That C code
    I wrote that's been compiling all these years since the 1980s now
    breaks because they reserved the word auto in the 1990s? 2000s?
    2010s?

    What are you talking about? ...

    "auto" has been a keyword for longer than C has been a language. It is,
    in fact, a carry over from one of C's predecessor languages (I'm not
    sure whether it was introduced in B or in BCPL). It actually made more sense in the predecessor language. In C, the only places where you're allowed to use "auto" are places where automatic storage duration is the default, so leaving out "auto" would give the same result as using it.
    As a result, C code almost never uses "auto". Something about it's predecessor language was different (I'm not sure what) that made "auto"
    a reasonable thing to use in that language.

    I've never used it. I didn't even know it was a C language keyword
    until I was reading the C Standard the other day. After reading what
    it does I still don't see why it exists. I came across a website
    referencing it that reads:

    "In the language C auto is a keyword for specifying a storage
    duration. When you create an auto variable it has an 'automatic
    storage duration'. We call these objects 'local variables'. In
    C, all variables in functions are local by default. That’s why
    the keyword auto is hardly ever used."

    It was needed by C's predecessor, B. It remained somewhat useful in C
    up until C99, when removal of the implicit int rule also removed what
    little remaining usefulness it had. That's the kind of thing that
    happens whenever a language lives long enough - if CAlive ever becomes
    anything other than vaporware, I'm sure that it will eventually start accumulating historical artifacts, too.

    This is what I'm talking about with the C committees being reaction-
    ary rather than visionary. They don't move in ways that make sense.
    They move trailing others who are moving in ways they think makes
    sense, effectively codifying what's seen in the real world.

    It should be more than that. The C committee should be steering.

    Once something has been standardized, it's extremely difficult,
    bordering on the impossible, to remove it if it later turns out to have
    been a mistake. "auto" is a prime example of this. Therefore, the
    committee generally prefers not to standardize a new feature until after
    it has been successfully implemented and put to use as an extension, so
    they can get a better idea of whether or not it can work. As a result, C
    is generally steered by the implementors, who in turn are often pushed
    by their users, rather than being steered by the committee. I don't see
    this as a particularly bad thing.

    I think your fundamental problem with this process is not who's doing
    the steering, but rather the fact that the people who are doing the
    steering are, in general, too competent, sane, and wise to steer the
    language in the directions you want it to go (which is not to say that
    they're unusually competent, sane, or wise).


    That's why C++ was able to give "auto" a new meaning, one that probably broke your code when you compiled it in C++.

    There was no code. It was a fictitious example conjured up to
    prove a point. It would work with any keyword that was later
    added to the language.

    With the exception of "restrict" all new keywords since C99 have been
    chosen from the name space reserved for implementations. It looks like "restrict" is not only the best example you could use, but also probably
    the only one. The addition of the other keywords has not broken any
    existing strictly conforming code, belying your claim that such breakage
    is inevitable.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rick C. Hodgin@21:1/5 to james...@alumni.caltech.edu on Thu Oct 31 09:38:56 2019
    On Thursday, October 31, 2019 at 11:37:08 AM UTC-4, james...@alumni.caltech.edu wrote:
    On Wednesday, October 30, 2019 at 9:29:28 PM UTC-4, Rick C. Hodgin wrote:
    This is what I'm talking about with the C committees being reaction-
    ary rather than visionary. They don't move in ways that make sense.
    They move trailing others who are moving in ways they think makes
    sense, effectively codifying what's seen in the real world.

    It should be more than that. The C committee should be steering.

    Once something has been standardized, it's extremely difficult,
    bordering on the impossible, to remove it if it later turns out to have
    been a mistake.

    Deprecation is wide-spread in every language I've ever used. Even
    in Java used for mobile Android development.

    It is expected that things will migrate / morph over time as newer
    and better and different technologies, abilities, features, or what-
    ever the cue is, change, that the tools used previously can still
    be used if you want those older features, but if you want to move
    forward some features need to be faded out.

    "auto" is a prime example of this. Therefore, the
    committee generally prefers not to standardize a new feature until after
    it has been successfully implemented and put to use as an extension, so
    they can get a better idea of whether or not it can work. As a result, C
    is generally steered by the implementors, who in turn are often pushed
    by their users, rather than being steered by the committee. I don't see
    this as a particularly bad thing.

    That's what I disagree with. C should be a steering committee,
    as well as a codifying body.

    I think your fundamental problem with this process is not who's doing
    the steering, but rather the fact that the people who are doing the
    steering are, in general, too competent, sane, and wise to steer the
    language in the directions you want it to go (which is not to say that they're unusually competent, sane, or wise).

    It's that there is a direction C needs to go. It needs the class.
    It needs to have an option to tighten up type checking. It needs
    some relaxations like not requiring the keyword struct on refer-
    ences, single-line comments, anonymous unions, and I think the 2nd
    biggest feature: should not REQUIRE forward declarations. The
    compiler should be allowed to morph into an n-pass compiler where
    unresolved forward declarations can be set aside on pass 0, and
    then become resolved for pass 1.

    To me, these are absolutely fundamental aspects of the nature of
    the language. It calls out for it by its own voice, and not even
    by my direction. When I sit back and look at what a C-like pro-
    gramming language needs, this is what IT tells me.

    That's why C++ was able to give "auto" a new meaning, one that probably broke your code when you compiled it in C++.

    There was no code. It was a fictitious example conjured up to
    prove a point. It would work with any keyword that was later
    added to the language.

    With the exception of "restrict" all new keywords since C99 have been
    chosen from the name space reserved for implementations. It looks like "restrict" is not only the best example you could use, but also probably
    the only one. The addition of the other keywords has not broken any
    existing strictly conforming code, belying your claim that such breakage
    is inevitable.

    Then use restrict as the example to prove my point.

    Deprecation exists for a reason. You cycle it out 2 or 4 or n
    generations, allowing it to be used all that time with the flag
    that it's been deprecated, and then remove it. That gives all
    actively software projects / developers plenty of time to make
    the changes. And those that aren't actively developed still run
    their old binary code just like always.

    It's a different philosophy of use, a different vision I have
    for C and C++. It's why CAlive will be successful. Many devel-
    opers out there have the same wishes I do, they just don't real-
    ize it yet because all they have is what they've been given.
    But you can look at several new programming languages lately
    and the features they incorporate and you can see I'm no alone
    in this vision. My goals are just to keep it closer to C than
    other goals. I want CAlive to compile existing C code with zero
    changes and no errors when using a compatibility mode. It will
    just do so with the CAlive LiveCode (edit-and-continue) features,
    as well as new ABI features like the inquiry, and several others.

    C will be relegated to niche areas increasingly as time goes on.
    Other languages running on today's incredibly fast hardware, are
    sufficient for 99% of apps. And in those cases where developers
    want more, they won't want to stay at C's low level. And they
    won't want to learn C++'s endless features and nuances to write
    clean, efficient C++ code. They want something simple, useful,
    powerful, flexible, easy to develop in/for, easy to update and
    maintain, etc. Enter CAlive's direct target / goals / focus,
    coupled also to a faith in Christ applied to the product and its
    license, bringing the reality of God back into our daily lives,
    yes even our programming lives. *GASP!* Yes, we are supposed
    to have God active in ALL areas of our lives, not just at a
    church on Sundays and Tuesdays for Bible Study. All the time He
    is to be maintained AHEAD of all of our efforts, including every-
    thing we do day-in / day-out.

    CAlive is coming into existence for a reason. And oh how I wish
    those associated with C would've been more accommodating to new
    ideas, having a vision, pushing forward rather than following be-
    hind. It would've saved me years of work.

    --
    Rick C. Hodgin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to David Brown on Thu Oct 31 10:14:20 2019
    David Brown <david.brown@hesbynett.no> writes:
    [...]
    Once "implicit int" was removed from the language, you could no longer
    write "auto x;" - you had to write "auto int x;", "register int x;" or
    just "int x;" (with the auto implied) for a non-static local variable.
    As there is no benefit in including the "auto", it is rarely seen. But compilers /must/ still support "auto int x;" if they try to be
    conforming, as it is still allowed even in modern standards. And many
    still allow "auto x;" (with implicit int) when compiling in lax modes,
    for support for older code.

    Yes, many compilers allow old forms for compatibility with earlier
    editions of the standard. But as far as the standard is concerned,
    allowing "auto x;" is no different from allowing any other non-C
    syntax. Backward compatibility extensions have no special status
    in the standard; the old forms are simply no longer C.

    (Expanding on what you wrote, not disagreeing.)

    --
    Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Working, but not speaking, for Philips Healthcare
    void Void(void) { Void(); } /* The recursive call of the void */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Rick C. Hodgin on Thu Oct 31 19:50:20 2019
    On 31/10/2019 17:38, Rick C. Hodgin wrote:
    On Thursday, October 31, 2019 at 11:37:08 AM UTC-4, james...@alumni.caltech.edu wrote:
    On Wednesday, October 30, 2019 at 9:29:28 PM UTC-4, Rick C. Hodgin wrote: >>> This is what I'm talking about with the C committees being reaction-
    ary rather than visionary. They don't move in ways that make sense.
    They move trailing others who are moving in ways they think makes
    sense, effectively codifying what's seen in the real world.

    It should be more than that. The C committee should be steering.

    Once something has been standardized, it's extremely difficult,
    bordering on the impossible, to remove it if it later turns out to have
    been a mistake.

    Deprecation is wide-spread in every language I've ever used. Even
    in Java used for mobile Android development.


    A very important feature of C as a language is that it does /not/
    deprecate anything without very good reason. C does not gain new
    features easily - and it loses features even more reluctantly. This is
    both a benefit and a limitation - but the C community (compiler vendors, programmers, and standards committee) have taken the view that C is to
    be a stable language. This means - unlike many other languages - you
    can take old C code, compile it with a new C compiler (on a platform
    that didn't exist when the code was written), and have a good chance of everything working correctly. The disadvantage is that the language
    does not gain much in the way of new features - C is what it is, and
    your choice is to accept that or find a different language.

    I have personally made updated versions of C programs I wrote over
    twenty years ago, and the language still works the same on modern tools.

    From the C99 Rationale:

    """
    The Committee is content to let C++ be the big and ambitious language.
    While some features of C++ may well be embraced, it is not the
    Committee’s intention that C become C++.
    """

    Indeed, I'd recommend reading the entire introduction to the C99
    Rationale to get an idea of how C changes.

    It is expected that things will migrate / morph over time as newer
    and better and different technologies, abilities, features, or what-
    ever the cue is, change, that the tools used previously can still
    be used if you want those older features, but if you want to move
    forward some features need to be faded out.

    That is common, but not necessary - and while it is often not a problem,
    it is not always desirable. That is why there is a place for a stable
    language like C, as well as more innovative and faster-changing languages.


    "auto" is a prime example of this. Therefore, the
    committee generally prefers not to standardize a new feature until after
    it has been successfully implemented and put to use as an extension, so
    they can get a better idea of whether or not it can work. As a result, C
    is generally steered by the implementors, who in turn are often pushed
    by their users, rather than being steered by the committee. I don't see
    this as a particularly bad thing.

    That's what I disagree with. C should be a steering committee,
    as well as a codifying body.

    The C community as a whole disagrees with you. You may want a more
    top-down for your own languages (and top-down has its benefits too), but
    that is not the way C works.


    I think your fundamental problem with this process is not who's doing
    the steering, but rather the fact that the people who are doing the
    steering are, in general, too competent, sane, and wise to steer the
    language in the directions you want it to go (which is not to say that
    they're unusually competent, sane, or wise).

    It's that there is a direction C needs to go.

    Why? C is fine as it is, receiving mostly just small fixes or improvements.

    It needs the class.

    No, it does not. That would give you a different language. There are
    already plenty of languages that are a bit like C, but have classes -
    there is no need for C to become one of them.

    It needs to have an option to tighten up type checking. It needs
    some relaxations like not requiring the keyword struct on refer-
    ences, single-line comments, anonymous unions, and I think the 2nd
    biggest feature: should not REQUIRE forward declarations. The
    compiler should be allowed to morph into an n-pass compiler where
    unresolved forward declarations can be set aside on pass 0, and
    then become resolved for pass 1.

    Single-line comments were added in C99, and anonymous unions moved from
    a very common extension to standard in C11. Surely it is a good idea to
    learn what the C language and the C standards say, before criticising it?


    To me, these are absolutely fundamental aspects of the nature of
    the language.

    Then you are not talking about C. They may well be features you like to
    see in programming languages - everyone has their own preferences and
    opinions. But you cannot call them "absolutely fundamental aspects of
    the nature of the language", given that the C language has been in heavy
    use for about 50 years and does not have these features!

    It calls out for it by its own voice, and not even
    by my direction. When I sit back and look at what a C-like pro-
    gramming language needs, this is what IT tells me.


    This is all your personal opinion and preferences, nothing more. If you
    feel that strongly, then use a different programming language that has
    the features you want, not C. You can't blame C for not being the
    language you want to use - that's just silly. It's like blaming an
    apple pie for not tasting chocolaty when chocolate cake is your favourite.

    That's why C++ was able to give "auto" a new meaning, one that probably >>>> broke your code when you compiled it in C++.

    There was no code. It was a fictitious example conjured up to
    prove a point. It would work with any keyword that was later
    added to the language.

    With the exception of "restrict" all new keywords since C99 have been
    chosen from the name space reserved for implementations. It looks like "restrict" is not only the best example you could use, but also probably
    the only one. The addition of the other keywords has not broken any
    existing strictly conforming code, belying your claim that such breakage
    is inevitable.

    Then use restrict as the example to prove my point.

    Deprecation exists for a reason. You cycle it out 2 or 4 or n
    generations, allowing it to be used all that time with the flag
    that it's been deprecated, and then remove it. That gives all
    actively software projects / developers plenty of time to make
    the changes. And those that aren't actively developed still run
    their old binary code just like always.

    It's a different philosophy of use, a different vision I have
    for C and C++. It's why CAlive will be successful. Many devel-
    opers out there have the same wishes I do, they just don't real-
    ize it yet because all they have is what they've been given.
    But you can look at several new programming languages lately
    and the features they incorporate and you can see I'm no alone
    in this vision. My goals are just to keep it closer to C than
    other goals. I want CAlive to compile existing C code with zero
    changes and no errors when using a compatibility mode. It will
    just do so with the CAlive LiveCode (edit-and-continue) features,
    as well as new ABI features like the inquiry, and several others.

    C will be relegated to niche areas increasingly as time goes on.

    Odd - C has existed for 50 years or so, and is still hugely popular and important. Most other languages either remain niche, or are popular for
    a few years before fading away. Your claims are completely disconnected
    from reality.

    Other languages running on today's incredibly fast hardware, are
    sufficient for 99% of apps. And in those cases where developers
    want more, they won't want to stay at C's low level.

    No one has ever suggested that C is the best language choice for all
    use. Most people use C for coding problems that suit C, and other
    languages for coding problems best solved in other languages.

    And they
    won't want to learn C++'s endless features and nuances to write
    clean, efficient C++ code.

    One of the few challengers to C for a long-lived and endlessly popular language, is C++.

    They want something simple, useful,
    powerful, flexible, easy to develop in/for, easy to update and
    maintain, etc.

    People who want that, use other languages. There are lots to choose from.

    Enter CAlive's direct target / goals / focus,
    coupled also to a faith in Christ applied to the product and its
    license, bringing the reality of God back into our daily lives,
    yes even our programming lives. *GASP!* Yes, we are supposed
    to have God active in ALL areas of our lives, not just at a
    church on Sundays and Tuesdays for Bible Study. All the time He
    is to be maintained AHEAD of all of our efforts, including every-
    thing we do day-in / day-out.


    If that's what you want, that's fine for /you/ - and anyone who shares
    your opinions and preferences. But it does not mean there is something
    wrong with C (or any other language).

    CAlive is coming into existence for a reason. And oh how I wish
    those associated with C would've been more accommodating to new
    ideas, having a vision, pushing forward rather than following be-
    hind. It would've saved me years of work.


    Did it never occur to you that no one who works with C was interested in
    any of your ideas? An idea being "new" does not automatically make it a
    good idea - and even an idea that is good for some programming languages
    is not automatically good for other languages. I have heard countless
    ideas from you over the years, and there were barely two or three that I
    ever thought had useful potential for any programming language - none
    that made sense for C. (There were more that could have been turned
    into good ideas, had you been open to discussion.) If you think your
    ideas will let you build a wonderful new language "CAlive", then great -
    go for it. But please cut out the delusion that you alone know what is
    good for C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rick C. Hodgin@21:1/5 to james...@alumni.caltech.edu on Fri Nov 1 07:20:27 2019
    On Wednesday, October 30, 2019 at 11:12:26 AM UTC-4, james...@alumni.caltech.edu wrote:
    On Tuesday, October 29, 2019 at 7:36:49 PM UTC-4, Rick C. Hodgin wrote:
    int8_t
    int16_t
    int32_t
    int64_t

    Why _t?

    In CAlive I defined signed and unsigned:

    s8, s16, s32, s64
    u8, u16, u32, u64

    And can you guess what these are?

    No. Without the _t, I would suspect them of being variable names, not
    types - which is the purpose of that convention.

    What is "int"? I come from an assembly background. INT is an
    interrupt. Okay, so in C int is an integer. Got it.

    You learn what key / core features of a language are and then
    use them as foundations. The same holds true for s8, s16, s32,
    s64, and u8, u16, u32, u64. I also define other forms which
    auto-upsize in use, including s24, s40, s48, s54, and their u
    counterparts. They allow for packed data storage of unusual
    sizes.

    When I first heard the website Yahoo, or the website YouTube,
    I thought those were ridiculous names. It would be like me
    coming up with MeTalkie for a communications website. It may
    sound silly today, but if it were popular it would just be a
    name.

    I once was talking to my computer illiterate neighbors who
    needed help getting on the Internet and getting setup with
    Windows 98 at that time.

    The mother and the daughter were there, and I asked them this
    literal question: "Is your web browser home page set to
    launch into Yahoo.com?" And they both burst out laughing so
    hard they started crying. They had no idea what I was talking
    about, and only knew the words from everyday experience. We
    still talk about that day. And when you look at that question
    from that point of view, it really is quite a series of words
    strung together.

    Some of C's syntax is quite a thing. C++ even more so. But
    once you get used to it, become fluent in it, it's all as it
    should be.

    We learn by doing, James. It's true of all things, including
    programming languages. But I'll still argue all day long that
    tagging things that will be used in every function with an _t
    is beyond ridiculous, into a whole new realm of even-more-than-
    ridiculous. It forces you to create your own typedefs or
    #define statements to make them something more desirable.

    --
    Rick C. Hodgin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philipp Klaus Krause@21:1/5 to All on Tue Aug 4 11:00:25 2020
    Am 25.10.19 um 16:26 schrieb Rick C. Hodgin:
    On Friday, October 25, 2019 at 9:53:05 AM UTC-4, Philipp Klaus Krause wrote:
    Am 25.10.19 um 14:26 schrieb Rick C. Hodgin:
    I'd like to propose that the nocode keyword be added to standard
    C. […]

    I don't think adding a keyword to silence warnings has a chance of being
    accepted. Try with an attribute instead.


    It introduces a new opportunity to issue diagnostics by giving
    the developer positive control over empty code blocks, whereas
    today it's an unknown relegated to parsing comments in a best
    case, or examining the logic in a worst case to see if it is
    actually doing what it should.

    With nocode, that uncertainty is replaced with certainty.

    It's a good addition.


    No, it is not. I doesn't change the semantics. Such stuff is exactly
    what attributes were introduced for (so adding keywords would not be necessary). Compare e.g. the fallthrough attribute.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philipp Klaus Krause@21:1/5 to All on Tue Aug 4 11:18:42 2020
    Am 31.10.19 um 02:29 schrieb Rick C. Hodgin:

    This is what I'm talking about with the C committees being reaction-
    ary rather than visionary.  They don't move in ways that make sense.
    They move trailing others who are moving in ways they think makes
    sense, effectively codifying what's seen in the real world.

    It should be more than that.  The C committee should be steering.

    While you might disagree with how the comitee works, the current way has
    even been stated explicitly. From the C2X charter N2086:

    "8. Codify existing practice to address evident deficiencies. Only those concepts that have some prior art should be accepted. (Prior art may
    come from implementations of languages other than C.) Unless some
    proposed new feature addresses an evident deficiency that is actually
    felt by more than a few C programmers, no new inventions should be entertained."

    "13. Unlike for C99, the consensus at the London meeting was that there
    should be no invention, without exception. Only those features that have
    a history and are in common use by a commercial implementation should be considered. Also there must be care to standardize these features in a
    way that would make the Standard and the commercial implementation
    compatible."

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)