Re: CFO: Why C?

From: VBDis (vbdis_at_aol.com)
Date: 09/07/03 

Date: 07 Sep 2003 12:39:19 GMT

Im Artikel <3f53176e$0$241$4d4ef98e@read.news.ch.uu.net>, wereHamster
<noname@nodomain.no> schreibt:

>Because of the pointer arithmetic.

Pointer arithmetic is obsolete. Other languages need no pointers, and the
compilers can create the same machine code from indexed expressions as well.
But I know that it's hard to forget about pointers, once one is convinced that
they are inevitable for writing non-trivial (and fast) programs.

Hint: access violations only can occur when pointers are used. Used in an
uncontrolled and wrong way, of course. But where no pointer arithmetic /can/ be
used, no such problems /can/ exist.

It's only required to forget about pointers and to learn how to write
intrinsically safe code, to get rid of such problems. At no extra cost, with
regards to flexibility and speed. Likewise you can forget about lint, ctags and
other helpers, these are obsolete as well.

>Sometimes this wak type safety is really
>good, 'read(int fd, void *buffer, size_t size)'

In VB this would be even simpler, just 'GET #file, var'. But not only in VB ;-)

DoDi

Relevant Pages

  • Re: int** to void**
    ... architectures (largely obsolete, I'd argue, at least for the OP) where ... Whilst you are probably right that there are currently no popular mainstream machines that have non-allbitszero null pointers, it is perhaps unwise to assume that things will stay that way. ...
    (comp.lang.c)
  • Re: CFO: Why C?
    ... > Pointer arithmetic is obsolete. ... Other languages need no pointers, ... > and the compilers can create the same machine code from indexed ... > extra cost, with regards to flexibility and speed. ...
    (comp.os.linux.development.apps)
  • Re: normalization of pointers...
    ... There's no such concept in Standard C. ... I read about it in the explanation of the far pointers... ... there they say that -"The only difference between huge pointers ... They are obsolete, used on the obsolete 8086 ...
    (comp.lang.c)
  • Re: Function pointers: performance penalty?
    ... pointers, with the compiler pointerfying direct function calls. ... Then look at the machine code. ... Are you suggesting that the name of the function is ... associated with an indirect call instruction. ...
    (comp.lang.c)
  • Re: Function pointers: performance penalty?
    ... Nope, function pointers are faster. ... with the compiler pointerfying direct function calls. ... Then look at the machine code. ... userfnaddr: dd userfn ...
    (comp.lang.c)