Rick, that's not how this works. David can post whatever he likes.
[obvious explanation snipped]
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.
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.
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.
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).
I haven't used B (or BCPL) - could it be that they did not have
different types, and thus no equivalent of "int x;" ?
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
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.
That's why C++ was able to give "auto" a new meaning, one that probably
broke your code when you compiled it in C++.
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?
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."
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.
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.
"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.
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.
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.
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.
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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 366 |
Nodes: | 16 (2 / 14) |
Uptime: | 06:25:47 |
Calls: | 7,812 |
Files: | 12,924 |
Messages: | 5,749,499 |