Re: A little disappointed

From: Alwyn (alwyn_at_blueyonder.co.uk)
Date: 11/29/04

  • Next message: Alwyn: "Re: A little disappointed"
    Date: Mon, 29 Nov 2004 13:41:22 GMT
    
    

    On Sun, 28 Nov 2004 22:27:39 +0000, Anthony Borla wrote:

    > "Alwyn" <alwyn@blueyonder.co.uk> wrote in message
    > news:pan.2004.11.28.12.49.33.431401@blueyonder.co.uk...
    >> On Sun, 28 Nov 2004 07:33:24 +1100, David White wrote:
    >>
    >> Pointers have been called 'the gotos of data' in that they
    >> introduce pitfalls for the unwary and are a source of
    >> programming errors.
    >>
    >
    > True.
    >
    > However, I'd suggest one way of improving matters is to make the unwary more
    > wary via eduaction / training rather than teaching avoidance [or as some
    > languages have done, disallow programmer access to the facility, thus
    > forcing avoidance].

    Well, the modern way of teaching C++ seems to be to introduce it as a
    higher-level language, without touching on pointers at all, or leaving
    them till a later stage of the learning process. This is the approach
    taken by Koenig and Moo in *Accelerated C++*, and also, I believe, by
    Glassborow in his beginners' book. Of course, we all know that C++ has
    pointers, which are treated almost identically to those of C, and so
    cannot be a real high-level language, but with its references and standard
    library, it makes a passable attempt at imitating one.

    Ideally, even an experienced C++ programmer is recommended never to handle
    raw pointers but rather use them wrapped up in so-called smart pointers.
    Since the only thing approaching a 'smart pointer' in the current
    standard is the fragile 'auto_ptr', one must either use a third-party
    library or invent one's own.

    Alwyn
     


  • Next message: Alwyn: "Re: A little disappointed"

    Relevant Pages

    • Re: Borlands IDE bugs and plans
      ... VB is a language that separates the programmer as ... Because of the lack of pointers, ... Or about the lack of support of ...
      (borland.public.delphi.non-technical)
    • Re: Starting to doubt fortran
      ... For "numerical code" the difference between C and Fortran is only ... Fortran pointers have a much richer ... with embedded assignments as a prime example of a write only language ... programmer dealing in the pointer/array minefield. ...
      (comp.lang.fortran)
    • Re: malloc() and implicit cast
      ... FAQ discusses a special case when programmer has ... FAQ: include the header, don't use the cast. ... In C language 'void*' pointers ...
      (comp.lang.c)
    • Re: Pointer of Reference ?
      ... the problem is that pnly "traditionally trained C programmers" as a class see pointers ... If the compiler has to dereference a pointer to achieve that goal, ... ASSERT wants a Boolean value, ... the programmer is forced to actually READ THE DOCUMENTATION OR THE FUNCTION DEFINITION, ...
      (microsoft.public.vc.mfc)
    • Re: Pointer equality and dereferencing
      ... matches your expectation because the implementation didn't bother (or didn't ... but if it's defined for one of the two pointers and the implementation doesn't keep track of the distinction between them, then the logical consequence is that using the wrong pointer will have the same result that is defined for the right pointer. ... programmer thought it couldn't keep track, ... If there's a disagreement between the programmer and the implementation, it shouldn't be about what the implementation can keep track of -- it should be about what behaviour, if any, is required by the C standard. ...
      (comp.std.c)