Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #98113 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2016-12-05 19:57 -0600 |
| Last post | 2016-12-06 12:06 +0800 |
| Articles | 20 on this page of 131 — 25 participants |
Back to article view | Back to comp.lang.c
"Let’s Stop Bashing C" Lynn McGuire <lynnmcguire5@gmail.com> - 2016-12-05 19:57 -0600
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 02:34 +0000
Re: "Let’s Stop Bashing C" BGB <cr88192@hotmail.com> - 2016-12-06 00:13 -0600
Re: "Let’s Stop Bashing C" BartC <bc@freeuk.com> - 2016-12-06 23:15 +0000
Re: "Let’s Stop Bashing C" BGB <cr88192@hotmail.com> - 2016-12-06 21:16 -0600
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 11:54 +0000
Re: "Let’s Stop Bashing C" BartC <bc@freeuk.com> - 2016-12-06 12:07 +0000
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 12:25 +0000
Re: "Let’s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-06 14:07 +0100
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 13:40 +0000
Re: "Let’s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-06 19:40 +0100
Re: "Lete2��s Stop Bashing C" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-06 13:55 -0500
Re: "Lete2��s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 19:13 +0000
Re: "Lete2��s Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-06 11:51 -0800
Re: "Lete2��s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 12:22 -0800
Re: "Lete2��s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-06 20:16 +0100
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 11:20 -0800
Re: "Lete2�™s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-06 22:15 +0100
Re: "Lete2�™s Stop Bashing C" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-06 16:49 -0500
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 14:24 -0800
Re: "Lete2�™s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 00:07 +0100
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-07 22:04 +0100
Re: micro-architectural details jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 23:44 +0100
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-07 23:02 +0000
Re: micro-architectural details Keith Thompson <kst-u@mib.org> - 2016-12-07 15:28 -0800
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 21:36 +0100
Re: micro-architectural details supercat@casperkitty.com - 2016-12-08 12:56 -0800
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 23:03 +0100
Re: micro-architectural details supercat@casperkitty.com - 2016-12-08 14:21 -0800
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 23:36 +0100
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-08 21:59 +0000
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 23:25 +0100
Re: micro-architectural details supercat@casperkitty.com - 2016-12-08 14:34 -0800
Re: micro-architectural details Noob <root@127.0.0.1> - 2016-12-08 23:59 +0100
Re: micro-architectural details Melzzzzz <mel@zzzzz.com> - 2016-12-09 00:18 +0100
Re: micro-architectural details fir <profesor.fir@gmail.com> - 2016-12-09 00:06 -0800
Re: micro-architectural details jt@toerring.de (Jens Thoms Toerring) - 2016-12-09 11:35 +0000
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-09 12:12 +0000
Re: micro-architectural details David Brown <david.brown@hesbynett.no> - 2016-12-09 13:33 +0100
Re: micro-architectural details Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-09 15:41 -0800
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 09:28 -0800
Re: micro-architectural details supercat@casperkitty.com - 2016-12-10 09:58 -0800
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 22:53 -0800
Re: micro-architectural details Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 03:10 -0600
Re: micro-architectural details jt@toerring.de (Jens Thoms Toerring) - 2016-12-11 13:48 +0000
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-11 14:43 +0000
Re: micro-architectural details Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 16:23 +0000
Re: micro-architectural details Keith Thompson <kst-u@mib.org> - 2016-12-11 12:53 -0800
Re: micro-architectural details Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 21:27 +0000
Re: micro-architectural details supercat@casperkitty.com - 2016-12-11 08:46 -0800
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:14 -0800
Re: micro-architectural details supercat@casperkitty.com - 2016-12-15 08:25 -0800
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:11 -0800
Re: micro-architectural details BartC <bc@freeuk.com> - 2016-12-15 14:28 +0000
Re: micro-architectural details David Brown <david.brown@hesbynett.no> - 2016-12-11 18:38 +0100
Re: micro-architectural details Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-15 00:25 -0800
Re: micro-architectural details supercat@casperkitty.com - 2016-12-09 07:42 -0800
Re: micro-architectural details Keith Thompson <kst-u@mib.org> - 2016-12-09 11:54 -0800
Re: micro-architectural details David Brown <david.brown@hesbynett.no> - 2016-12-09 10:27 +0100
Re: other missing features (no-brainers) Noob <root@127.0.0.1> - 2016-12-09 17:05 +0100
Re: micro-architectural details jt@toerring.de (Jens Thoms Toerring) - 2016-12-09 09:51 +0000
Re: "Lete2�™s Stop Bashing C" Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 20:42 -0500
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 14:16 -0800
Re: "Lete2�™s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 00:31 +0100
Re: "Let's Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-06 15:55 -0800
Re: "Let's Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 01:01 +0100
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-06 16:42 -0800
Re: "Lete2�™s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 01:55 +0100
Re: "Lete2�™s Stop Bashing C" supercat@casperkitty.com - 2016-12-07 07:11 -0800
Re: "Lete2??s Stop Bashing C" Ike Naar <ike@iceland.freeshell.org> - 2016-12-06 23:05 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 00:43 +0100
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 03:06 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 11:47 +0100
Re: "Lete2??s Stop Bashing C" Thiago Adams <thiago.adams@gmail.com> - 2016-12-07 03:10 -0800
Re: "Lete2??s Stop Bashing C" Thiago Adams <thiago.adams@gmail.com> - 2016-12-07 03:13 -0800
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 11:47 +0000
Re: "Lete2??s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-07 12:08 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-07 23:45 +0100
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 00:22 +0100
Re: "Lete2??s Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-07 15:32 -0800
Re: "Let's Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 01:25 +0100
Re: "Let's Stop Bashing C" supercat@casperkitty.com - 2016-12-07 16:36 -0800
Re: "Let's Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-07 17:09 -0800
Re: "Let's Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 10:28 +0100
Re: "Let's Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-08 08:34 -0800
Re: "Let's Stop Bashing C" Gareth Owen <gwowen@gmail.com> - 2016-12-08 20:08 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 10:24 +0100
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 15:49 +0100
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 15:23 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 16:58 +0100
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 18:57 +0000
Re: "Lete2??s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 15:29 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 17:09 +0100
Re: "Lete2??s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 16:41 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 17:04 +0100
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 17:15 +0100
Re: "Lete2??s Stop Bashing C" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-08 11:34 -0500
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 18:40 +0100
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 10:00 -0800
Re: "Lete2??s Stop Bashing C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 19:05 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 19:58 +0100
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 08:22 -0800
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 20:12 +0100
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 11:40 -0800
Re: "Lete2??s Stop Bashing C" Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 02:44 -0600
Re: "Lete2??s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-08 16:22 +0000
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 20:14 +0100
Re: "Lete2??s Stop Bashing C" Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 02:19 -0600
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 07:44 -0800
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-08 22:05 +0100
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-08 22:14 +0100
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-09 10:39 +0100
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-08 13:33 -0800
Re: "Lete2??s Stop Bashing C" David Brown <david.brown@hesbynett.no> - 2016-12-09 11:13 +0100
Re: "Lete2??s Stop Bashing C" Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 06:27 -0600
Re: "Lete2??s Stop Bashing C" supercat@casperkitty.com - 2016-12-07 07:17 -0800
Re: "Lete2??s Stop Bashing C" Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 23:43 -0600
Re: "Lete2??s Stop Bashing C" Ike Naar <ike@iceland.freeshell.org> - 2016-12-07 07:41 +0000
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 11:45 +0100
Re: "Lete2??s Stop Bashing C" Keith Thompson <kst-u@mib.org> - 2016-12-07 09:22 -0800
Re: "Lete2??s Stop Bashing C" jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-07 11:49 +0100
Re: "Lete2??s Stop Bashing C" Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 09:28 -0500
Re: "Lete2��s Stop Bashing C" "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-06 14:22 -0500
Re: Subject field encoding Noob <root@127.0.0.1> - 2016-12-07 21:40 +0100
Re: Subject field encoding Keith Thompson <kst-u@mib.org> - 2016-12-07 13:01 -0800
Re: Subject field encoding Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-07 16:02 -0500
Re: "Lete2�™s Stop Bashing C" asetofsymbols@gmail.com - 2016-12-08 15:50 -0800
Re: "Let’s Stop Bashing C" Richard Heathfield <rjh@cpax.org.uk> - 2016-12-06 19:07 +0000
Re: "Let€™s Stop Bashing C" Xcott Craver <nospam@nospam.invalid> - 2016-12-07 16:48 -0500
Re: "Let's Stop Bashing C" Noob <root@127.0.0.1> - 2016-12-07 23:29 +0100
Re: "Let’s Stop Bashing C" "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-06 12:06 +0800
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2016-12-05 19:57 -0600 |
| Subject | "Let’s Stop Bashing C" |
| Message-ID | <o255ru$p1n$1@dont-email.me> |
"Let’s Stop Bashing C"
http://h2co3.org/blog/index.php/2016/12/01/lets-stop-bashing-c/
A critique of "Let’s stop copying C"
https://eev.ee/blog/2016/12/01/lets-stop-copying-c/
Lynn
[toc] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-06 02:34 +0000 |
| Message-ID | <o25823$ufe$1@dont-email.me> |
| In reply to | #98113 |
On 06/12/16 01:57, Lynn McGuire wrote: > "Let’s Stop Bashing C" > http://h2co3.org/blog/index.php/2016/12/01/lets-stop-bashing-c/ Interesting article. Actually, the part I found most interesting was the level of maturity displayed by many of those who disagreed with the author (in much the same way that snails display a level of speed and wendy-houses display a level of volume). > A critique of "Let’s stop copying C" > https://eev.ee/blog/2016/12/01/lets-stop-copying-c/ I must confess I didn't read this in any great detail, so I can't comment on anything specific. But I would certainly agree with the title: let's stop copying C! For pity's sake: those of us who want C already know where to find it. Those of us who sometimes want C but with extra toys also know where to find C++. If you (and, Lynn, I am using "you" in the generic sense here, not targeting you personally!) --- I was saying, if you don't like either of those, that's absolutely fine. So use something different. But what's the point of using something that's pretty much the same as the thing you don't like? C is what it is. For some people, it's a great choice. For others, not so good. For example, anyone who can't understand integer division after about 10 seconds explanation is not going to do well with C. Let them eat Python (or whatever). But bashing C is as completely and utterly pointless and fruitless as bashing any other language. You don't like it? Use something different. What's the problem? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2016-12-06 00:13 -0600 |
| Message-ID | <o25ku4$et8$1@news.albasani.net> |
| In reply to | #98115 |
On 12/5/2016 8:34 PM, Richard Heathfield wrote:
> On 06/12/16 01:57, Lynn McGuire wrote:
>> "Let’s Stop Bashing C"
>> http://h2co3.org/blog/index.php/2016/12/01/lets-stop-bashing-c/
>
> Interesting article. Actually, the part I found most interesting was the
> level of maturity displayed by many of those who disagreed with the
> author (in much the same way that snails display a level of speed and
> wendy-houses display a level of volume).
>
>> A critique of "Let’s stop copying C"
>> https://eev.ee/blog/2016/12/01/lets-stop-copying-c/
>
> I must confess I didn't read this in any great detail, so I can't
> comment on anything specific. But I would certainly agree with the
> title: let's stop copying C!
>
> For pity's sake: those of us who want C already know where to find it.
> Those of us who sometimes want C but with extra toys also know where to
> find C++.
>
I mostly use C, but also have my own script language (BGBScript2), and
while I initially disagreed with the article, some things in my own
language design differ from C, so, ...
but, the languages have different roles:
C is good for implementing stuff;
BS2 is for writing script logic.
typically BS2 code is loaded directly as source-code on start-up.
BS2 is basically statically typed using manual memory management (via
new/delete operators), but many things use automatic storage duration
(bound by the lifetime of the parent scope). some things which would be
implicit in GC languages are more explicit in this language.
some typical dynamic language features exist, but are adjusted to match
the language semantics. ex: there are closures and exit-only
continuations (internally handled as a special type of thrown exception).
point-for-point (for BS2):
Textual Inclusion:
well, my script lang doesn't do #include, but more because at this point
header inclusion is the bane of compiler efficiency, effectively
unnecessary and difficult to make efficient.
instead, things link together horizontally, and packages/imports may be
used (but, typically thus far most stuff is going in the toplevel).
Optional Block Delimiters:
uses conventional C style rules.
Bitwise Operator Precedence:
currently located between add/subtract and shifts.
Negative Modulo:
modulo of negatives is negative.
Leading Zero for octal:
the '0' prefix notation is deprecated in favor of '0c'
otherwise still supported.
FWIW: numbers allow '_' as a digit separator.
No power operator:
currently also lacks an explicit power operator
it is possible to write "x.pow(y)" which does basically similar.
C-style for loops:
currently uses traditional C loop syntax.
Switch with default fallthrough:
currently fallthrough is the default.
Type first:
declaration syntax basically similar to Java and friends
* and & exist but are type prefixes (rather than declarator prefixes).
Weak typing:
most types may be promoted implicitly
converting to a narrower type may result in a warning without a cast.
direct conversion between integer and pointer types isn't allowed.
technically "(((*byte)null)+0xF00BA5)" and "(ptr-((*byte)null))" works
generally the integers are seen as relative to a pointer.
Integer division:
int/int => int
Bytestrings
string type is semi-opaque, but generally either ASCII or UTF-16
canonically they are UTF-16, but compiler uses ASCII if it fits.
casting a string to a pointer may make a copy of it internally.
depends on whether the string format matches the pointer type.
Increment and decrement:
done same as C and friends.
!: done same as C.
Single return and out parameters:
single return, but out paramenters may be declared like "(&type var)".
Silent Errors:
generally uses try/catch and exceptions.
Nulls:
has nulls.
Assignment as expression:
assignment operator is an expression.
No hyphens in identifiers:
same, allows alphanumeric, _, $, and unicode chars.
Braces and semicolons:
uses braces and semicolons.
some things similar to C:
statically typed;
has structs and pointers;
supports pointer arithmetic;
supports objects / arrays with automatic storage duration;
currently uses manual memory management;
code structure is fairly freeform;
variables/functions may be declared globally or in packages.
any amount of stuff can be put in a source file.
...
currently enforcement of bounds-checks is a bit hit or miss.
TODO: make it smarter (currently, they are opt-in).
some other differences from C:
triple-quote ("""...""") syntax for block strings.
built in support for numeric vectors (similar to GLSL or HLSL).
memory layout for class instances is undefined.
only struct has a well defined layout.
class instances don't even necessarily have a 'flat' memory layout.
misc stuff:
MyObject obj;
obj=new {field1: value1, field2:value2, ...}:MyObject(arg1, arg2);
...
or such...
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-06 23:15 +0000 |
| Message-ID | <o27goq$cuv$1@dont-email.me> |
| In reply to | #98125 |
On 06/12/2016 06:13, BGB wrote: > On 12/5/2016 8:34 PM, Richard Heathfield wrote: >> For pity's sake: those of us who want C already know where to find it. >> Those of us who sometimes want C but with extra toys also know where to >> find C++. >> > > I mostly use C, but also have my own script language (BGBScript2), and > while I initially disagreed with the article, some things in my own > language design differ from C, so, ... > > > but, the languages have different roles: > C is good for implementing stuff; > BS2 is for writing script logic. > typically BS2 code is loaded directly as source-code on start-up. I also have use two levels of language. Since I've just found how to do table-format in 'markdown', here's a list comparing C with my two languages: https://github.com/bartg/langs/blob/master/list.md (Don't know if comparison with the dynamic one is meaningful, but I threw it in there anyway.) > point-for-point (for BS2): > > Textual Inclusion: > well, my script lang doesn't do #include, but more because at this point > header inclusion is the bane of compiler efficiency, effectively > unnecessary and difficult to make efficient. > > instead, things link together horizontally, and packages/imports may be > used (but, typically thus far most stuff is going in the toplevel). I use a hierarchical module system which is manageable for the dynamic language (and the interpreter takes care of loading order), but is troublesome for the static one. I have plans for a scheme to eliminate all such problems, but it would need a new compiler. (So, any global, exported or shared entity is still only declared/defined in one place, and the import system can still control visibility, but there are no restrictions on compilation order and allows circular dependencies. Nice, but it'll have to wait. The static language mainly exists to implement one project anyway.) > C-style for loops: > currently uses traditional C loop syntax. > > Switch with default fallthrough: > currently fallthrough is the default. > !: done same as C. > uses braces and semicolons. So you haven't moved too far from C then! The first thing I would have to do is get rid of braces. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2016-12-06 21:16 -0600 |
| Message-ID | <o27uu9$gtm$1@news.albasani.net> |
| In reply to | #98220 |
On 12/6/2016 5:15 PM, BartC wrote:
> On 06/12/2016 06:13, BGB wrote:
>> On 12/5/2016 8:34 PM, Richard Heathfield wrote:
>
>>> For pity's sake: those of us who want C already know where to find it.
>>> Those of us who sometimes want C but with extra toys also know where to
>>> find C++.
>>>
>>
>> I mostly use C, but also have my own script language (BGBScript2), and
>> while I initially disagreed with the article, some things in my own
>> language design differ from C, so, ...
>>
>>
>> but, the languages have different roles:
>> C is good for implementing stuff;
>> BS2 is for writing script logic.
>> typically BS2 code is loaded directly as source-code on start-up.
>
> I also have use two levels of language.
>
> Since I've just found how to do table-format in 'markdown', here's a
> list comparing C with my two languages:
>
> https://github.com/bartg/langs/blob/master/list.md
>
> (Don't know if comparison with the dynamic one is meaningful, but I
> threw it in there anyway.)
>
ok.
>> point-for-point (for BS2):
>>
>> Textual Inclusion:
>> well, my script lang doesn't do #include, but more because at this point
>> header inclusion is the bane of compiler efficiency, effectively
>> unnecessary and difficult to make efficient.
>>
>> instead, things link together horizontally, and packages/imports may be
>> used (but, typically thus far most stuff is going in the toplevel).
>
> I use a hierarchical module system which is manageable for the dynamic
> language (and the interpreter takes care of loading order), but is
> troublesome for the static one. I have plans for a scheme to eliminate
> all such problems, but it would need a new compiler.
>
> (So, any global, exported or shared entity is still only
> declared/defined in one place, and the import system can still control
> visibility, but there are no restrictions on compilation order and
> allows circular dependencies. Nice, but it'll have to wait.
>
> The static language mainly exists to implement one project anyway.)
>
in my language:
parsing does not depend on visible declarations;
declarations can be in any relative order
well, apart from the the occasional compiler bug or similar
result is that things are generally parsed independently, but the main
compile stage typically takes everything in an "image"/"assembly" and
compiles it all at once.
effectively, it is early bound, and so pretty much everything needs to
be visible at compile time. as a result, it may spend multiple passes
mostly propagating declaration types.
unlike its more dynamic predecessor (the original BGBScript), the
semantics for some constructions were constrained to be more compatible
with being early-bound, statically typed, and using manual MM.
one example is that all bindings need to be statically visible within
the lexical environment at the point they are used. this is true even
though the language (also) has dynamically-scoped variables, which
require lexical visibility despite having dynamic identity.
dependencies may be cyclic within a given image, but dependencies
between images are required to be acyclic (well, in theory, I don't do
much yet with the language that goes beyond a single image).
>> C-style for loops:
>> currently uses traditional C loop syntax.
>>
>> Switch with default fallthrough:
>> currently fallthrough is the default.
>> !: done same as C.
>> uses braces and semicolons.
>
> So you haven't moved too far from C then!
>
> The first thing I would have to do is get rid of braces.
>
it is close enough to not make porting code fragments unnecessarily painful.
here are a few fragments which are more native to the language (from a
"mob_spider" entity-class):
<--
public void fallGravity()
{
vec3xf org1, org2;
org1=origin+0.04*velocity;
if(!Bt2Ent_EntityMoveCheckCollide(this, org1))
{
origin=org1;
if(((int)flags)&ENTFL_ZFLIP)
{ velocity=velocity+#[0, 0, 9.8*0.04]; }
else
{ velocity=velocity-#[0, 0, 9.8*0.04]; }
}else
{
velocity=#[0, 0, 0];
}
}
public void tick()
{
vec3xf org1, org2;
vec3f dir, lorg;
float dist;
int i, j, k;
// sprite_sz=#[128, 96];
// sprite="sprites/spider/spider0_1";
// radius=24;
// height=96;
if(!world_player)
return;
fallGravity();
dir=world_player.origin-this.origin;
dist=dir.len;
dir=dir/(dist+1);
if(dist>64.0)
{
// frgl_printf("Dist=%f\n", dist);
return;
}
// if(dist<48)
// Bt2Ent_KillPlayer();
i=((int)(world_time*8))&1;
// i=i*2-1;
sprite="sprites/spider/spider_walk0_1";
if(i)
{ sprite_sz=#[-128, 96]; }
else
{ sprite_sz=#[ 128, 96]; }
lorg=origin;
org1=origin+0.3*dir;
// if(IsoTile_CheckEntMoveCollidePos(this))
// { origin=lorg; }
if(!Bt2Ent_EntityMoveCheckCollide(this, org1))
{ origin=org1; return; }
org2=org1+#[0, 0, 1.25];
if(!Bt2Ent_EntityMoveCheckCollide(this, org2))
{ origin=org2; }
}
-->
here is another fragment (from a JPEG decoder test in the language):
<--
public void PDJPG_CopyOutBlock8B(
PDJPG_Context ctx, *int ibuf,
*byte obuf, int xs, int ys,
int x, int y)
{
*int cs;
*byte ct;
int i0, i1, i2, i3, i4, i5, i6, i7;
int i, j, k;
if(((x+8)>xs) || ((y+8)>ys))
{
for(i=0; i<8; i++)
{
if((y+i)>=ys)
continue;
cs=ibuf+i*8;
ct=obuf+(y+i)*xs+x;
for(j=0; j<8; j++)
{
if((x+j)>=xs)
continue;
k=*cs++;
if(k<0)k=0;
if(k>255)k=255;
*ct=k;
ct++;
}
}
return;
}
for(i=0; i<8; i++)
{
cs=ibuf+i*8;
ct=obuf+(y+i)*xs+x;
j=cs[0]|cs[1]|cs[2]|cs[3]|cs[4]|cs[5]|cs[6]|cs[7];
if(j>>8)
{
i0=cs[0]; i1=cs[1]; i2=cs[2]; i3=cs[3];
i4=cs[4]; i5=cs[5]; i6=cs[6]; i7=cs[7];
if(i0<0)i0=0; if(i1<0)i1=0;
if(i2<0)i2=0; if(i3<0)i3=0;
if(i4<0)i4=0; if(i5<0)i5=0;
if(i6<0)i6=0; if(i7<0)i7=0;
if(i0>255)i0=255; if(i1>255)i1=255;
if(i2>255)i2=255; if(i3>255)i3=255;
if(i4>255)i4=255; if(i5>255)i5=255;
if(i6>255)i6=255; if(i7>255)i7=255;
ct[0]=i0; ct[1]=i1; ct[2]=i2; ct[3]=i3;
ct[4]=i4; ct[5]=i5; ct[6]=i6; ct[7]=i7;
}else
{
ct[0]=(cs[0]); ct[1]=(cs[1]);
ct[2]=(cs[2]); ct[3]=(cs[3]);
ct[4]=(cs[4]); ct[5]=(cs[5]);
ct[6]=(cs[6]); ct[7]=(cs[7]);
}
}
}
-->
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-06 11:54 +0000 |
| Message-ID | <o268qi$hj0$2@dont-email.me> |
| In reply to | #98115 |
On 06/12/16 11:12, Stefan Ram wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> But bashing C is as completely and utterly pointless and fruitless as >> bashing any other language. You don't like it? Use something different. >> What's the problem? > > People cannot always make that decision themselves. I realise that, /but/... > In > vocational training or on their jobs, sometimes, they might > be told to learn or use C, while they might prefer to learn > or use some other language. ...Yes, but in those situations griping about the language isn't going to do them any good, so why bother? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-06 12:07 +0000 |
| Message-ID | <o269kh$kna$1@dont-email.me> |
| In reply to | #98115 |
On 06/12/2016 02:34, Richard Heathfield wrote: > But bashing C is as completely and utterly pointless and fruitless as > bashing any other language. You don't like it? Use something different. > What's the problem? If there was always a choice, then that would be fine. But sometimes there is very little choice. If you need a language which has a compiler for given platform, you want it fast, you want it small, you want it malleable enough to fit around any interface, then C may not only be at the top of the list, but also at the bottom! Or you have to deal with C because third party libraries use it for their code, headers and documentation. Or the the OS heavily makes use of it, such that you can't prise the two apart (eg. Linux). Then, why not bash it if someone is not happy with some aspects? Sometimes you can't 'use something different'. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-06 12:25 +0000 |
| Message-ID | <o26am1$o34$1@dont-email.me> |
| In reply to | #98145 |
On 06/12/16 12:07, BartC wrote: > On 06/12/2016 02:34, Richard Heathfield wrote: > >> But bashing C is as completely and utterly pointless and fruitless as >> bashing any other language. You don't like it? Use something different. >> What's the problem? > > If there was always a choice, then that would be fine. Oh, there's always a choice (although sometimes the choice may not be palatable). > But sometimes there is very little choice. If you need a language which > has a compiler for given platform, you want it fast, you want it small, > you want it malleable enough to fit around any interface, then C may not > only be at the top of the list, but also at the bottom! Sure. But if you /change/ it to move it further up the list (to get it off the bottom), is it not very likely that the things you change are also going to move it further down the list (and thus take it off the top)? > Or you have to deal with C because third party libraries use it for > their code, headers and documentation. Or the the OS heavily makes use > of it, such that you can't prise the two apart (eg. Linux). In which case you have to deal with C /as it is/, not as you would like it to be. > Then, why not bash it if someone is not happy with some aspects? What's the point? You're wasting your time complaining about something you can't change (and, if you did change it, it would no longer be the thing you need, in which case you'd have sawn off the branch you were sitting on). > Sometimes you can't 'use something different'. If your complaints were successful, it would /become/ something different, and then, by your own arguments, it would be something you can no longer use. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-06 14:07 +0100 |
| Message-ID | <o26d40$ia$1@dont-email.me> |
| In reply to | #98146 |
On 06/12/16 13:25, Richard Heathfield wrote: > On 06/12/16 12:07, BartC wrote: >> On 06/12/2016 02:34, Richard Heathfield wrote: >> >>> But bashing C is as completely and utterly pointless and fruitless as >>> bashing any other language. You don't like it? Use something different. >>> What's the problem? >> >> If there was always a choice, then that would be fine. > > Oh, there's always a choice (although sometimes the choice may not be > palatable). > Often there is a perfectly reasonable choice - use C, adapted to the features you want. If you (like me) think it is a daft idea to have block limiters optional, then always include them in the code you write. Problem solved. If you (like me) think the bitwise operator precedence is silly, then always use brackets or put the bitwise stuff and the comparison in different expressions. Problem solved. If you (like me) think that default fall-through in switches is madness, then use "break" religiously and enable compiler warnings to help. Problem solved. If you (like me) don't like complicated and unclear declarations, then use typedef's as needed until everything /is/ clear. Problem solved. And so on. Just because C lets you write "risky" or illegible code, does not mean you have to write your code that way - even if you have no choice but to program in C. Of course, that doesn't solve the problem of dealing with other people's code. But other people's code is always terrible, no matter what language you are using. <http://dilbert.com/strip/2013-02-24> <http://dilbert.com/strip/2014-08-12>
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-06 13:40 +0000 |
| Message-ID | <o26f27$7r8$1@dont-email.me> |
| In reply to | #98151 |
On 06/12/16 13:07, David Brown wrote: > On 06/12/16 13:25, Richard Heathfield wrote: >> On 06/12/16 12:07, BartC wrote: >>> On 06/12/2016 02:34, Richard Heathfield wrote: >>> >>>> But bashing C is as completely and utterly pointless and fruitless as >>>> bashing any other language. You don't like it? Use something different. >>>> What's the problem? >>> >>> If there was always a choice, then that would be fine. >> >> Oh, there's always a choice (although sometimes the choice may not be >> palatable). >> > > Often there is a perfectly reasonable choice - use C, adapted to the > features you want. > > If you (like me) think it is a daft idea to have block limiters > optional, then always include them in the code you write. Problem solved. > > If you (like me) think the bitwise operator precedence is silly, then > always use brackets or put the bitwise stuff and the comparison in > different expressions. Problem solved. > > If you (like me) think that default fall-through in switches is madness, > then use "break" religiously and enable compiler warnings to help. > Problem solved. > > If you (like me) don't like complicated and unclear declarations, then > use typedef's as needed until everything /is/ clear. Problem solved. > > > And so on. > > Just because C lets you write "risky" or illegible code, does not mean > you have to write your code that way - even if you have no choice but to > program in C. > > > Of course, that doesn't solve the problem of dealing with other people's > code. But other people's code is always terrible, no matter what > language you are using. > > <http://dilbert.com/strip/2013-02-24> > <http://dilbert.com/strip/2014-08-12> And although it's difficult to believe, sometimes our own code is terrible: <http://dilbert.com/strip/1996-01-31> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-06 19:40 +0100 |
| Message-ID | <o270js$b8g$1@dont-email.me> |
| In reply to | #98146 |
Le 06/12/2016 à 13:25, Richard Heathfield a écrit : > What's the point? You're wasting your time complaining about something > you can't change (and, if you did change it, it would no longer be the > thing you need, in which case you'd have sawn off the branch you were > sitting on). C can't test for overflow. Most software in C is not prepared to deal with overflow. lcc-win proposes a pseudo-function called overflow() that will give you the value of the overflow flag. Did "Navia's C" as you call it, get heavy and full of unnecessary features because lcc-win programmers can easily test overflow??? Your opinion is that C should remain frozen with Turbo C's language. I absolutely do not agree with that
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2016-12-06 13:55 -0500 |
| Subject | Re: "Lete2��s Stop Bashing C" |
| Message-ID | <o271gi$ejv$1@dont-email.me> |
| In reply to | #98191 |
On Tuesday December 6 2016 13:40, in comp.lang.c, "jacobnavia" <jacob@jacob.remcomp.fr> wrote: > Le 06/12/2016 à 13:25, Richard Heathfield a écrit : >> What's the point? You're wasting your time complaining about something >> you can't change (and, if you did change it, it would no longer be the >> thing you need, in which case you'd have sawn off the branch you were >> sitting on). > > C can't test for overflow. Agree and disagree. I agree with an assertion that the C standard does not define an interface or algorithm to detect arithmetic overflow. I disagree with an assertion that a C program cannot programmatically determine if an arithmetic operation will overflow or not. > Most software in C is not prepared to deal with overflow. Citation, please. It is conceivable that much software written in C cannot "deal with overflow" because the programs use of arithmetic operations is confined to a range of values that are guaranteed not to overflow, either in general, or on the intended compilation and execution platform. I grant that /some/ quantity of software written in C will fail to deal properly with arithmetic overflow, but "most"? You need to justify that claim. [snip advertisement] > Your opinion is that C should remain frozen with Turbo C's language. I have yet to see Richard Heathfield claim /that/ opinion. Again, you need to cite your source, or retract your claim. > I absolutely do not agree with that With what? Your claim, or the (spuriously credited) opinion that "C should remain frozen with Turbo C's language". I will assume that you mean that you agree that C should not "remain frozen with Turbo C's language". -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-06 19:13 +0000 |
| Subject | Re: "Lete2��s Stop Bashing C" |
| Message-ID | <o272im$j2m$1@dont-email.me> |
| In reply to | #98193 |
On 06/12/16 18:55, Lew Pitcher wrote: > On Tuesday December 6 2016 13:40, in comp.lang.c, "jacobnavia" > <jacob@jacob.remcomp.fr> wrote: > >> Le 06/12/2016 à 13:25, Richard Heathfield a écrit : >>> What's the point? You're wasting your time complaining about something >>> you can't change (and, if you did change it, it would no longer be the >>> thing you need, in which case you'd have sawn off the branch you were >>> sitting on). >> >> C can't test for overflow. > > Agree and disagree. > > I agree with an assertion that the C standard does not define an interface or > algorithm to detect arithmetic overflow. > > I disagree with an assertion that a C program cannot programmatically > determine if an arithmetic operation will overflow or not. > >> Most software in C is not prepared to deal with overflow. > > Citation, please. > > It is conceivable that much software written in C cannot "deal with overflow" > because the programs use of arithmetic operations is confined to a range of > values that are guaranteed not to overflow, either in general, or on the > intended compilation and execution platform. > > I grant that /some/ quantity of software written in C will fail to deal > properly with arithmetic overflow, but "most"? You need to justify that > claim. > > [snip advertisement] > >> Your opinion is that C should remain frozen with Turbo C's language. > > I have yet to see Richard Heathfield claim /that/ opinion. Again, you need to > cite your source, or retract your claim. Well, I wouldn't actually go so far as to say "Turbo C" (after all, it had a few bugs). But do I think that there should be few, if any, changes to the language? Yes, I do. I have no problem with innovation and development, but let's just call it something else, not C. The ISO C Committee get around this by calling the new version C99, or C11, or whatever, but the trouble with that is that there is some perception that the older incarnations of C are thus obsolesced, and I think that's a bad thing. If you want to innovate, yes, innovate! But while you're in a creative mood, for pity's sake think up a new name. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-06 11:51 -0800 |
| Subject | Re: "Lete2��s Stop Bashing C" |
| Message-ID | <lnpol43kgb.fsf@kst-u.example.com> |
| In reply to | #98196 |
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> Well, I wouldn't actually go so far as to say "Turbo C" (after all, it
> had a few bugs). But do I think that there should be few, if any,
> changes to the language? Yes, I do. I have no problem with innovation
> and development, but let's just call it something else, not C. The ISO C
> Committee get around this by calling the new version C99, or C11, or
> whatever, but the trouble with that is that there is some perception
> that the older incarnations of C are thus obsolesced, and I think that's
> a bad thing.
The ISO C committee probably uses the term C99 and C11 informally, but
the word "C11" does not appear anywhere in ISO/IEC 9899:2011 (E).
And the idea that older editions are obsolete is not just perception,
it's an explicit statement. Paragraph 6 of the C11 Foreword says:
This third edition cancels and replaces the second edition, ISO/IEC
9899:1999, which has been technically revised.
(In spite of that, I feel no particular obligation to pretend that the
C90 and C99 standards no longer exist, even if I prefer to use the later
edition when I can.)
> If you want to innovate, yes, innovate! But while you're in a creative
> mood, for pity's sake think up a new name.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-06 12:22 -0800 |
| Subject | Re: "Lete2��s Stop Bashing C" |
| Message-ID | <afe877c8-b232-4181-9987-29edd0875286@googlegroups.com> |
| In reply to | #98203 |
On Tuesday, December 6, 2016 at 1:50:12 PM UTC-6, Keith Thompson wrote: > The ISO C committee probably uses the term C99 and C11 informally, but > the word "C11" does not appear anywhere in ISO/IEC 9899:2011 (E). > And the idea that older editions are obsolete is not just perception, > it's an explicit statement. Paragraph 6 of the C11 Foreword says: > > This third edition cancels and replaces the second edition, ISO/IEC > 9899:1999, which has been technically revised. > > (In spite of that, I feel no particular obligation to pretend that the > C90 and C99 standards no longer exist, even if I prefer to use the later > edition when I can.) No committee that would make statements like the above should be taken seriously. If one presumes that future versions of the Standard will likely continue the tradition embodied by that statement, that would imply that it's impossible to write code whose meaning can't spontaneously change as a result of factors over which the programmer has no control. By comparison, many other languages and protocols define means by which documents or implementations can specify what versions of the standard they require or support; while support for some old versions may be deprecated, that does not generally happen without a substantial transition period, and even after such period the meanings of the original wouldn't change. Even though new implementations would no longer be required to be compatible with very old ones, the requirements for an implementation that *wanted* to be compatible would remain the same.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-06 20:16 +0100 |
| Subject | Re: "Lete2��s Stop Bashing C" |
| Message-ID | <o272ns$ikt$1@dont-email.me> |
| In reply to | #98193 |
Le 06/12/2016 à 19:55, Lew Pitcher a écrit : > [snip advertisement] "Advertissement" ??? Look I am always wrong with you. There is no point in answering that
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-06 11:20 -0800 |
| Subject | Re: "Lete2�™s Stop Bashing C" |
| Message-ID | <8f359715-238c-42b4-b53f-5c5511725fdb@googlegroups.com> |
| In reply to | #98193 |
On Tuesday, December 6, 2016 at 12:55:36 PM UTC-6, Lew Pitcher wrote:
> I agree with an assertion that the C standard does not define an interface or
> algorithm to detect arithmetic overflow.
>
> I disagree with an assertion that a C program cannot programmatically
> determine if an arithmetic operation will overflow or not.
In Standard C, determining whether an arithmetic operation would produce an
overflow is generally much more difficult than performing the operation in
the non-overflow case. In many cases, it will be difficult or impossible
for a compiler to generate code which is anywhere near as efficient as would
be possible if the language supported better overflow semantics.
For example, there are three important situations with respect to overflow:
1. If no overflows occurred, the program needs to report that no overflows
occurred.
2. If overflows occurred *that would cause a program to yield
arithmetically-incorrect output*, the program needs to report that
such an overflow occurred [and not do anything else wacky].
3. If overflows occurred *but* they would *not* cause a program to yield
arithmetically-incorrect output, a compiler should be allowed to either
report the overflow or not at its convenience.
If a program needs to e.g. perform a sum-of-products calculation and
report if any overflows occurred, and if the code uses manual overflow
checking, a compiler will have no choice but to perform all of the
calculations in the exact sequence given. If a compiler knows that it
can exploit part #3 in the semantics above, however, it may be able to
split the calculation into parts that can't overflow and then add those
together. For example, given something like:
#pragma set_flag_on_overflow // Or whatever
int sum(int *x, int *y, int n)
{
int total = 0;
for (int i=0; i<n; i++)
total += x[i]*y[i];
return total;
}
a compiler for a 64-bit machine might be able to optimize that to something
like:
int sum(int *x, int *y, int n)
{
long long total = 0;
if (n & 1)
total = *x++ * *y++;
for (int i=0; i<n; i+=2)
total += (int64_t)x[i]*y[i] + (int64_t)x[i+1]*y[i+1];
if (total < INT_MIN || total > INT_MAX)
__set_overflow_flag();
return total;
}
That would only require one overflow check for every two loop iterations,
but would not report all situations where the total went outside the range
of "int" at once step but came back within the range of "int" in a later
step. If the language doesn't have any way to tell the compiler such
semantics are desirable, there's no way a compiler could possibly achieve
such optimizations.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-06 22:15 +0100 |
| Subject | Re: "Lete2�™s Stop Bashing C" |
| Message-ID | <o279nh$f1b$1@dont-email.me> |
| In reply to | #98199 |
Le 06/12/2016 à 20:20, supercat@casperkitty.com a écrit : > In Standard C, determining whether an arithmetic operation would produce an > overflow is generally much more difficult than performing the operation in > the non-overflow case. In many cases, it will be difficult or impossible > for a compiler to generate code which is anywhere near as efficient as would > be possible if the language supported better overflow semantics. A compiler can (as I did with lcc-win) test always the overflow flag after each operation that can generate an overflow condition. If the overflow happens, execution will go to a user defined function that defaults to exit() with an appropiate message in stderr. That costs around 4% when I wrote the first version of the software, but can go down to 1-2% when you try to optimize a little bit. We, discussed this here extensively in a thread that I started in comp.std.c and here in Sep 1, 2009.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2016-12-06 16:49 -0500 |
| Subject | Re: "Lete2�™s Stop Bashing C" |
| Message-ID | <o27bm1$mgq$1@dont-email.me> |
| In reply to | #98209 |
On Tuesday December 6 2016 16:15, in comp.lang.c, "jacobnavia" <jacob@jacob.remcomp.fr> wrote: > Le 06/12/2016 à 20:20, supercat@casperkitty.com a écrit : >> In Standard C, determining whether an arithmetic operation would produce an >> overflow is generally much more difficult than performing the operation in >> the non-overflow case. In many cases, it will be difficult or impossible >> for a compiler to generate code which is anywhere near as efficient as >> would be possible if the language supported better overflow semantics. > > A compiler can (as I did with lcc-win) test always the overflow flag > after each operation that can generate an overflow condition. > > If the overflow happens, execution will go to a user defined function > that defaults to exit() with an appropiate message in stderr. Jacob, just a question... Why not have your code generate a signal (like the floatingpoint error signal SIGFPE, but for integer operations) when an arithmetic overflow occurs? That way, arithmetic overflow could be handled in the same manner as floatingpoint exceptions and leave the programmer in charge of whether (and how) to handle the occurrence. Yes, it would be a non-standard extension of C's asynchronous signal handling facilities, but would fit with both the current programming practice that ignore overflows, /and/ the current programming practice that handles asynchronous math failures through signals. What do you think? Is this approach worthwhile? > That costs around 4% when I wrote the first version of the software, but > can go down to 1-2% when you try to optimize a little bit. > > We, discussed this here extensively in a thread that I started in > comp.std.c and here in Sep 1, 2009. > -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-06 14:24 -0800 |
| Subject | Re: "Lete2�™s Stop Bashing C" |
| Message-ID | <f80db400-a179-48ad-ac63-f6e954c08b8c@googlegroups.com> |
| In reply to | #98213 |
On Tuesday, December 6, 2016 at 3:49:12 PM UTC-6, Lew Pitcher wrote: > Why not have your code generate a signal (like the floatingpoint error signal > SIGFPE, but for integer operations) when an arithmetic overflow occurs? That > way, arithmetic overflow could be handled in the same manner as floatingpoint > exceptions and leave the programmer in charge of whether (and how) to handle > the occurrence. Yes, it would be a non-standard extension of C's asynchronous > signal handling facilities, but would fit with both the current programming > practice that ignore overflows, /and/ the current programming practice that > handles asynchronous math failures through signals. Much of the cost of overflow trapping comes not from the expense of checking for overflow, but rather the limitations it imposes upon a compiler's ability to optimize the sequence in which operations are performed. If the expression "x+y+z" occurs in a loop, even if x and z do not change within the loop, a compiler with precisely-defined overflow semantics would need to evaluate that using two additions and two overflow checks. If the compiler could specify looser overflow semantics, however, it could evaluate (x+z) outside the loop and, if that subexpression didn't overflow, it could replace x+y+z with (x+z)+y, saving an overflow check within the loop. That would cause a compiler not to report overflow in cases where (x+y) would overflow but (x+z)+y wouldn't, but in cases where the latter expression can be evaluated without overflow the fact that (x+y)+z can't be evaluated without overflow shouldn't matter.
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web