Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: "Death To C" |
| Date | 2015-05-06 13:49 +0100 |
| Organization | go, ion artisan! |
| Message-ID | <mid2ik$trt$1@dont-email.me> (permalink) |
| References | (2 earlier) <20150504224134.0e897c71@maxa-pc> <gq6gkapsgtcnsrmulg96q7nvd1v919i5u6@4ax.com> <mia43h$gc2$1@dont-email.me> <pan.2015.05.06.07.10.05.543000@nowhere.invalid> <micko3$bvi$1@dont-email.me> |
On 06/05/15 09:53, Bartc wrote:
> On 06/05/2015 08:10, Nobody wrote:
>> On Tue, 05 May 2015 10:57:03 +0100, Bartc wrote:
>>
>>> It's not necessarily slow. If the bounds *are* known, then frequently you
>>> will also know that accesses are within bounds:
>>>
>>> for (i=0; i<=len(A); ++i)
>>> A[i]=0;
>>>
>>> No bounds checking needed here.
>>
>> "<="?
>
> Sorry, I'm more used to 1-based code.
In which case, why did you set i to 0?
In 0-based languages, iterating over an array in ascending order is
idiomatic: for(i = 0; i < N; i++) is the pattern. Your fingers get used
to it in time.
> But an automatic system would deal with it properly:
So does a programmer who is used to the idiom, and he can deal with it
without incurring the overhead of automatic bounds-checking. There is no
such thing as a free lunch. Everything costs cycles. The programmer who
can be trusted to think about bounds himself is able to squeeze more out
of the processor than someone who has to rely on an automated
bounds-check to save his code from blowing up. It is absolutely right
and proper that automatic bounds-checking systems should be available,
but absolutely wrong that everyone should be forced to use them, or even
to be forced into the decision of whether or not to use them all the
time. So if an implementation wants to offer optional bounds-checking
via a command line switch, I'm all for it. But it has to be
switchable-offable.
> the compiler would
> either object immediately, or would leave in bounds-checking (maybe the
> loop is exited early, in a more elaborate case, or an indexing operation
> is guarded by a conditional, so perhaps this is what is intended. So
> allow it, but leave in the bounds check in the case the coder has no
> idea what he's doing.)
This penalises programmers who actually do know what they're doing. A
wise programmer will consider the possibility that he doesn't know what
he's doing, and (if the option is available to him) switch on
bounds-checking for extra checks during debugging and testing, and then
(if the drop in performance indicates it) switch it off and re-test.
> (It also demonstrates the errorprone nature of C for-loops I'm always
> complaining about.
Everything is error-prone. English is error-prone, as your sentence
above amply demonstrates. (Not a dig - I make plenty of errors in
English, too.) My own view is that C's for loops, like any sharp tool,
can be dangerous and should be handled with care. But, like any sharp
tool, they can be extraordinarily useful. I would not want to see the
syntax changed just because /some/ people find them to be particularly
error-prone.
> A 'for' that didn't need you to specify the exact
> compare op needed, or better still a 'forall', would have fewer such
> problems.)
The latter would be a better option. Not quite sure how you'd implement
it in C, though, given that the compiler may not be able to tell how
many items forall should cover. Consider:
void foo(int *p)
{
size_t n;
forall(p, n) /* how does the compiler know how many times to run this
loop? */
{
foo(p[n]);
}
}
It would be a fairly major change to the language, and would almost
certainly involve information about the array being squirrelled away by
the compiler, which squirrelling would inevitably incur a performance
overhead.
--
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
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
"Death To C" Lynn McGuire <lmc@winsim.com> - 2015-05-04 14:41 -0500
Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:16 +0200
Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-04 13:26 -0700
Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:51 +0200
Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-04 22:02 +0100
Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-05 00:06 +0200
Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-04 13:22 -0700
Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:41 +0200
Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-04 20:25 -0500
Bounds checking in C (Was: "Death To C") gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-05 02:15 +0000
Re: Bounds checking in C (Was: "Death To C") BGB <cr88192@hotmail.com> - 2015-05-06 10:23 -0500
Re: "Death To C" Les Cargill <lcargill99@comcast.com> - 2015-05-04 21:36 -0500
Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:01 -0500
Re: "Death To C" Les Cargill <lcargill99@comcast.com> - 2015-05-05 12:23 -0500
Re: "Death To C" CHIN Dihedral <dihedral88888@gmail.com> - 2015-05-05 03:06 -0700
Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 17:43 +1200
Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:00 -0500
Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:13 -0500
Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 19:15 +1200
Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 02:41 -0500
Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 20:12 +1200
Re: "Death To C" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-05 06:48 +0000
Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-05 10:57 +0100
Re: "Death To C" asetofsymbols@gmail.com - 2015-05-05 16:53 -0700
Re: "Death To C" Nobody <nobody@nowhere.invalid> - 2015-05-06 08:10 +0100
Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 09:53 +0100
Re: "Death To C" Richard Heathfield <rjh@cpax.org.uk> - 2015-05-06 13:49 +0100
Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 14:29 +0100
Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-06 09:43 -0700
Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 18:24 +0100
Re: "Death To C" asetofsymbols@gmail.com - 2015-05-08 00:44 -0700
Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-08 13:49 +0100
Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-04 22:15 +0100
Re: "Death To C" BGB <cr88192@hotmail.com> - 2015-05-08 09:09 -0500
Re: "Death To C" Stephen Sprunk <stephen@sprunk.org> - 2015-05-04 16:18 -0500
Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 12:49 +1200
Re: "Death To C" raltbos@xs4all.nl (Richard Bos) - 2015-05-08 21:52 +0000
Re: "Death To C" Merikissa <merikissa@no.spam.net> - 2015-05-10 04:04 +0300
Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-13 08:11 -0700
Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-13 10:00 -0700
Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-13 18:20 +0100
Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-14 10:47 -0700
Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-14 11:09 -0700
Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-15 19:21 +0100
Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-16 09:10 -0700
Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-16 20:45 +0100
Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-17 09:38 -0700
Re: "Death To C" raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:47 +0000
Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-17 12:20 +0100
Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-13 10:24 -0700
Re: "Death To C" David Brown <david.brown@hesbynett.no> - 2015-05-13 22:01 +0200
Re: "Death To C" Nobody <nobody@nowhere.invalid> - 2015-05-14 07:48 +0100
csiph-web