pointers

Discussion in 'C++' started by mikethebike, Sep 21, 2009.

  1. mikethebike

    mikethebike Guest

    Hi
    why needs C++ pointers while f. ex. VB.NET doesn't make use of such?

    In other words why does VB.NET not need pointers?

    Thanks
    Michael
     
    mikethebike, Sep 21, 2009
    #1
    1. Advertising

  2. mikethebike

    Ian Collins Guest

    mikethebike wrote:
    > Hi
    > why needs C++ pointers while f. ex. VB.NET doesn't make use of such?


    Because it can works with raw memory (or memory mapped devices).

    > In other words why does VB.NET not need pointers?


    Because it can't work with raw memory.

    --
    Ian Collins
     
    Ian Collins, Sep 21, 2009
    #2
    1. Advertising

  3. Ian Collins <> writes:

    > mikethebike wrote:
    >> Hi
    >> why needs C++ pointers while f. ex. VB.NET doesn't make use of such?

    >
    > Because it can works with raw memory (or memory mapped devices).
    >
    >> In other words why does VB.NET not need pointers?

    >
    > Because it can't work with raw memory.


    VB.NET also work with memory. And AFAIK, it's as raw as for any
    program.

    Perhaps you want to mean that C allow you to implement all kinds of
    bugs, while VB.NET prevents you to implement whole classes of bugs?


    When you write "raw memory work" you actually mean "bug provoking
    memory work".


    PS: VB.NET being taken here as a prototype for any class of program
    working in a controled environment, such as java, ruby, perl,
    python, lisp, haskell, ocaml, etc.
    --
    __Pascal Bourguignon__
     
    Pascal J. Bourguignon, Sep 21, 2009
    #3
  4. mikethebike

    Ian Collins Guest

    Pascal J. Bourguignon wrote:
    > Ian Collins <> writes:
    >
    >> mikethebike wrote:
    >>> Hi
    >>> why needs C++ pointers while f. ex. VB.NET doesn't make use of such?

    >> Because it can works with raw memory (or memory mapped devices).
    >>
    >>> In other words why does VB.NET not need pointers?

    >> Because it can't work with raw memory.

    >
    > VB.NET also work with memory. And AFAIK, it's as raw as for any
    > program.
    >
    > Perhaps you want to mean that C allow you to implement all kinds of
    > bugs, while VB.NET prevents you to implement whole classes of bugs?


    Oh, so device drivers are a class of bug? I'd better stop writing them
    then!

    > PS: VB.NET being taken here as a prototype for any class of program
    > working in a controled environment, such as java, ruby, perl,
    > python, lisp, haskell, ocaml, etc.


    None of which are much use for the close to the metal programming a lot
    of us enjoy.

    --
    Ian Collins
     
    Ian Collins, Sep 21, 2009
    #4
  5. Ian Collins <> writes:

    > Pascal J. Bourguignon wrote:
    >> Ian Collins <> writes:
    >>
    >>> mikethebike wrote:
    >>>> Hi
    >>>> why needs C++ pointers while f. ex. VB.NET doesn't make use of such?
    >>> Because it can works with raw memory (or memory mapped devices).
    >>>
    >>>> In other words why does VB.NET not need pointers?
    >>> Because it can't work with raw memory.

    >>
    >> VB.NET also work with memory. And AFAIK, it's as raw as for any
    >> program.
    >>
    >> Perhaps you want to mean that C allow you to implement all kinds of
    >> bugs, while VB.NET prevents you to implement whole classes of bugs?

    >
    > Oh, so device drivers are a class of bug? I'd better stop writing
    > them then!
    >
    >> PS: VB.NET being taken here as a prototype for any class of program
    >> working in a controled environment, such as java, ruby, perl,
    >> python, lisp, haskell, ocaml, etc.

    >
    > None of which are much use for the close to the metal programming a
    > lot of us enjoy.


    I don't say anything for programs that really need to be close to the
    metal. The problem is that 99% of the programs written in C or C++
    have no need to be that close to the metal, and should rather be
    written in other languages.


    kernel.org be written in C, ok. Anything on sourceforge.net written
    in C or C++ is almost certainly language mismatch.

    --
    __Pascal Bourguignon__
     
    Pascal J. Bourguignon, Sep 21, 2009
    #5
  6. On Sep 21, 7:27 am, (Pascal J. Bourguignon) wrote:
    > Ian Collins <> writes:
    > > Pascal J. Bourguignon wrote:
    > >> Ian Collins <> writes:

    >
    > >>> mikethebike wrote:
    > >>>> Hi
    > >>>> why needs C++ pointers while f. ex. VB.NET doesn't make use of such?
    > >>> Because it can works with raw memory (or memory mapped devices).

    >
    > >>>> In other words why does VB.NET not need pointers?
    > >>> Because it can't work with raw memory.

    >
    > >> VB.NET also work with memory. And AFAIK, it's as raw as for any
    > >> program.

    >
    > >> Perhaps you want to mean that C allow you to implement all kinds of
    > >> bugs, while VB.NET prevents you to implement whole classes of bugs?

    >
    > > Oh, so device drivers are a class of bug? I'd better stop writing
    > > them then!

    >
    > >> PS: VB.NET being taken here as a prototype for any class of program
    > >> working in a controled environment, such as java, ruby, perl,
    > >> python, lisp, haskell, ocaml, etc.

    >
    > > None of which are much use for the close to the metal programming a
    > > lot of us enjoy.

    >
    > I don't say anything for programs that really need to be close to the


    Wrong. You said "for any program". And whether or not you PS note
    actually applied to that initial outburst is entirely unclear.

    > metal. The problem is that 99% of the programs written in C or C++
    > have no need to be that close to the metal, and should rather be
    > written in other languages.


    So your initial "AFAIK, it's as raw as for any program" was wrong?

    > kernel.org be written in C, ok. Anything on sourceforge.net written
    > in C or C++ is almost certainly language mismatch.


    Which is clearly a VERY different message from your first post.
    I guess you a backtracking a bit now that your original over-
    zealous bluster was called.

    I'm surprised that after all these years and all your education
    and experience that you still swallow the "pointers are evil" BS.

    KHD
     
    Keith H Duggar, Sep 21, 2009
    #6
  7. Keith H Duggar <> writes:

    > On Sep 21, 7:27 am, (Pascal J. Bourguignon) wrote:
    >> Ian Collins <> writes:
    >> > Pascal J. Bourguignon wrote:
    >> >> Ian Collins <> writes:

    >>
    >> >>> mikethebike wrote:
    >> >>>> Hi
    >> >>>> why needs C++ pointers while f. ex. VB.NET doesn't make use of such?
    >> >>> Because it can works with raw memory (or memory mapped devices).

    >>
    >> >>>> In other words why does VB.NET not need pointers?
    >> >>> Because it can't work with raw memory.

    >>
    >> >> VB.NET also work with memory. And AFAIK, it's as raw as for any
    >> >> program.

    >>
    >> >> Perhaps you want to mean that C allow you to implement all kinds of
    >> >> bugs, while VB.NET prevents you to implement whole classes of bugs?

    >>
    >> > Oh, so device drivers are a class of bug? I'd better stop writing
    >> > them then!

    >>
    >> >> PS: VB.NET being taken here as a prototype for any class of program
    >> >> working in a controled environment, such as java, ruby, perl,
    >> >> python, lisp, haskell, ocaml, etc.

    >>
    >> > None of which are much use for the close to the metal programming a
    >> > lot of us enjoy.

    >>
    >> I don't say anything for programs that really need to be close to the

    >
    > Wrong. You said "for any program". And whether or not you PS note
    > actually applied to that initial outburst is entirely unclear.


    If I'm saying the tautology:

    for any integer x, ((x<0) and (x>0)) ==> (x=sqrt(x+1))

    and you cannot find any integer such as x=sqrt(x+1), then it means
    that there is no integer x such as (x<0) and (x>0).


    Analoguously, there is no program that really need to be close to the
    metal. This is exactly what I'm saying.


    >> metal. The problem is that 99% of the programs written in C or C++
    >> have no need to be that close to the metal, and should rather be
    >> written in other languages.

    >
    > So your initial "AFAIK, it's as raw as for any program" was wrong?
    >
    >> kernel.org be written in C, ok. Anything on sourceforge.net written
    >> in C or C++ is almost certainly language mismatch.

    >
    > Which is clearly a VERY different message from your first post.
    > I guess you a backtracking a bit now that your original over-
    > zealous bluster was called.


    It may look like I'm backtracking, but it's only a concession to the
    vicious circle constituted by unix<=>C.

    I admit that you write a unix kernel and its driver in C, because I
    let the definition of unix to be a kernel written in C.


    But doing this concession, I require that you do the concession that
    anything else mustn't be written in C.


    And I say nothing about the bugs inherent in implementing a kernel in
    C. I'll only say that I'd prefer to work on a kernel NOT implemented
    in C, for example, a kernel with drivers implemented in Lisp, such as
    the Lisp Machine kernel, (or Movitz for a modern example). But other
    programming languages are also admissible, such as Oberon or Modula-3.


    > I'm surprised that after all these years and all your education
    > and experience that you still swallow the "pointers are evil" BS.


    Pointers as implemented by C compilers are evil indeed.
    Checked pointers would be admissible.

    The C or C++ languages themselves says that it is illegal (or
    technically, "undefined") to access via a pointer beyond the allocated
    memory block. Why don't the compilers control this?


    Notice that we're talking about "classes of program working in a
    controled environment". This is the category we're talking about.
    Above, any occurence of "languages", must be taken as the typical
    category in which their implementations generally fall. You may have
    exceptionnal implementations (eg a C interpreter that controls all
    pointer accesses, or a Common Lisp compiler without any safety
    optimization that would let you implement buffer overflows), but we're
    not considering these exceptional cases.


    A meeting point that could satisfy both of us (but remember that I'm
    asserting that programs don't need to be that close to the metal, so I
    don't really see the point), would be Modula-3, where you can define
    SAFE or UNSAFE modules, UNSAFE modules being those that would use
    unsafe primitives, such as random pointer computations. Typically,
    you would have to prove formally their correctness and to intensively
    test these unsafe modules before incoporating them in a system.

    Another meeting point would be that when I say that programs don't
    need to be close to the metal, I'm speaking of source code, of
    programs as written by human. If there are automatic tools that
    compile high level code into binary code close to the metal, I don't
    really mind (assuming the compilers are formally proved, and closely
    checked).


    --
    __Pascal Bourguignon__
     
    Pascal J. Bourguignon, Sep 21, 2009
    #7
  8. (Pascal J. Bourguignon) writes:
    > It may look like I'm backtracking, but it's only a concession to the
    > vicious circle constituted by unix<=>C.


    I must say that there's another vicious circle under unix, which is
    that of the kind of processors we have, and this is probably the worst
    of the two.

    Since unix developed, processors evolved to fulfill the needs of unix,
    and unix adapted to match well these processors. The end of this
    co-evolution is the ix86 Intel processor. :-(

    (Notice that the PDP-11 processor was little endian, and that all
    big-endian processors have been droped in favor of a little endian
    one for running the majority of unix systems).


    The evilness of this vicious circle, is that you will be comparing the
    performance of other systems and languages as implemented on
    processors optimized for unix and C, instead of comparing it on
    processors that would have evolved on other branches, optimized for
    other kinds of systems and languages.

    Notice that C programs compiled with the Zeta-C compiler running on
    Lisp Machine weren't faster than Lisp programs compiled on that system
    (just to take an example I have in mind, there were other examples).



    Nowadays, it seems to me we have computers fast enough that we could
    stepback and rethink a little the global architecture of our computer,
    and try something else.

    If Apple can lose cycles to have jumping icons, couldn't we lose some
    cycles to have safer and smarter software?

    --
    __Pascal Bourguignon__
     
    Pascal J. Bourguignon, Sep 21, 2009
    #8
  9. In message
    <>,
    mikethebike <> writes
    >Hi
    >why needs C++ pointers while f. ex. VB.NET doesn't make use of such?
    >
    >In other words why does VB.NET not need pointers?


    It _does_ need pointers. What do you think is happening here?

    Dim x As Object
    x = New MyType()

    VB's "reference-type variables" are just pointers by another name.

    --
    Richard Herring
     
    Richard Herring, Sep 21, 2009
    #9
  10. mikethebike

    joseph cook Guest

    On Sep 21, 9:24 am, (Pascal J. Bourguignon) wrote:

    > The C or C++ languages themselves says that it is illegal (or
    > technically, "undefined") to access via a pointer beyond the allocated
    > memory block.  Why don't the compilers control this?


    What? Control it exactly how? If I have a library API call that
    returns the address of say, a shared memory buffer, how exactly is
    this supposed to be flagged by a compiler?

    I suspect there are millions of intellegent critiques of C and C++,
    but you haven't found one yet.

    Your question is equivalant to asking why when I run an executable on
    a different machine with less memory, why the compiler doesn't flag
    that and throw a warning if there isn't enough space. Of course, I
    may not even have a compiler installed on my new machine, but why
    should that stop it?

    Joe C
     
    joseph cook, Sep 21, 2009
    #10
  11. mikethebike

    Bo Persson Guest

    Pascal J. Bourguignon wrote:
    > Ian Collins <> writes:
    >
    >> mikethebike wrote:
    >>> Hi
    >>> why needs C++ pointers while f. ex. VB.NET doesn't make use of
    >>> such?

    >>
    >> Because it can works with raw memory (or memory mapped devices).
    >>
    >>> In other words why does VB.NET not need pointers?

    >>
    >> Because it can't work with raw memory.

    >
    > VB.NET also work with memory. And AFAIK, it's as raw as for any
    > program.
    >
    > Perhaps you want to mean that C allow you to implement all kinds of
    > bugs, while VB.NET prevents you to implement whole classes of bugs?
    >
    >


    Nobody is forcing you to use pointers. If you can write better
    programs without them, why don't you just do that?

    The language also contains goto, which allows you to write horrible
    spaghetti-style programs. Most people don't.


    Bo Persson
     
    Bo Persson, Sep 21, 2009
    #11
  12. mikethebike

    James Kanze Guest

    On Sep 21, 6:26 pm, joseph cook <> wrote:
    > On Sep 21, 9:24 am, (Pascal J. Bourguignon) wrote:


    > > The C or C++ languages themselves says that it is illegal
    > > (or technically, "undefined") to access via a pointer beyond
    > > the allocated memory block. Why don't the compilers control
    > > this?


    > What? Control it exactly how? If I have a library API call
    > that returns the address of say, a shared memory buffer, how
    > exactly is this supposed to be flagged by a compiler?


    The C (and C++) standard was carefully written to make such
    implementations possible, and they have existed (and maybe still
    do). Catching such errors, however, does require "fat"
    pointers, which have significant performance overhead.

    > I suspect there are millions of intellegent critiques of C and
    > C++, but you haven't found one yet.


    Actually, this is one. In a well designed language, bounds
    checking would not have such exhorbitant overhead. The way
    pointers and arrays work in C (and thus in C++) is a serious
    flaw in the language.

    --
    James Kanze
     
    James Kanze, Sep 22, 2009
    #12
  13. mikethebike

    James Kanze Guest

    On Sep 21, 8:02 pm, "Bo Persson" <> wrote:
    > Pascal J. Bourguignon wrote:


    > Nobody is forcing you to use pointers. If you can write better
    > programs without them, why don't you just do that?


    You need pointers at some level, in order to implement dynamic
    data structures, and to navigate between objects.

    > The language also contains goto, which allows you to write
    > horrible spaghetti-style programs. Most people don't.


    There are two major sources of bugs regarding pointers. The
    first is due to pointer arithmetic and the lack of bounds
    checking. If you're implementing something like std::vector,
    you can't avoid it; otherwise, you should be using something
    like std::vector, which can eliminate an entire class of errors.
    The second is using pointers to objects which no longer exist;
    this can be detected by means of some sort of garbage collection
    (which means that the memory for an object cannot be recycled as
    long as a pointer to that object exists), but only partially,
    since it can't affect pointers to objects not allocated
    dynamically.

    --
    James Kanze
     
    James Kanze, Sep 22, 2009
    #13
  14. James Kanze wrote:
    > On Sep 21, 6:26 pm, joseph cook <> wrote:
    >> On Sep 21, 9:24 am, (Pascal J. Bourguignon) wrote:

    >
    >>> The C or C++ languages themselves says that it is illegal
    >>> (or technically, "undefined") to access via a pointer beyond
    >>> the allocated memory block. Why don't the compilers control
    >>> this?

    >
    >> What? Control it exactly how? If I have a library API call
    >> that returns the address of say, a shared memory buffer, how
    >> exactly is this supposed to be flagged by a compiler?

    >
    > The C (and C++) standard was carefully written to make such
    > implementations possible, and they have existed (and maybe still
    > do). Catching such errors, however, does require "fat"
    > pointers, which have significant performance overhead.
    >
    >> I suspect there are millions of intellegent critiques of C and
    >> C++, but you haven't found one yet.

    >
    > Actually, this is one. In a well designed language, bounds
    > checking would not have such exhorbitant overhead. The way
    > pointers and arrays work in C (and thus in C++) is a serious
    > flaw in the language.


    This is contradiction to what you wrote above, no?
    Above you wrote it would require a fat pointer, and here you wrote that
    it wouldn't need big overhead. Can you explain why?
     
    Vladimir Jovic, Sep 22, 2009
    #14
  15. mikethebike

    Krice Guest

    On 22 syys, 09:42, James Kanze <> wrote:
    > The way pointers and arrays work in C (and thus in C++) is
    > a serious flaw in the language.


    I thought they work perfectly if used properly.
     
    Krice, Sep 22, 2009
    #15
  16. mikethebike

    James Kanze Guest

    On Sep 22, 8:27 am, Vladimir Jovic <> wrote:
    > James Kanze wrote:
    > > On Sep 21, 6:26 pm, joseph cook <> wrote:
    > >> On Sep 21, 9:24 am, (Pascal J. Bourguignon) wrote:


    > >>> The C or C++ languages themselves says that it is illegal
    > >>> (or technically, "undefined") to access via a pointer
    > >>> beyond the allocated memory block. Why don't the
    > >>> compilers control this?


    > >> What? Control it exactly how? If I have a library API
    > >> call that returns the address of say, a shared memory
    > >> buffer, how exactly is this supposed to be flagged by a
    > >> compiler?


    > > The C (and C++) standard was carefully written to make such
    > > implementations possible, and they have existed (and maybe
    > > still do). Catching such errors, however, does require
    > > "fat" pointers, which have significant performance overhead.


    > >> I suspect there are millions of intellegent critiques of C
    > >> and C++, but you haven't found one yet.


    > > Actually, this is one. In a well designed language, bounds
    > > checking would not have such exhorbitant overhead. The way
    > > pointers and arrays work in C (and thus in C++) is a serious
    > > flaw in the language.


    > This is contradiction to what you wrote above, no?


    No.

    > Above you wrote it would require a fat pointer, and here you
    > wrote that it wouldn't need big overhead. Can you explain why?


    Above I wrote that in C or C++ it would require a fat pointer.
    In a well designed language, this wouldn't necessarily be the
    case; the fat pointer is required because C and C++ don't
    distinguish between a pointer to a single object, and a pointer
    to the first element of an array.

    --
    James Kanze
     
    James Kanze, Sep 22, 2009
    #16
  17. mikethebike

    Bo Persson Guest

    Vladimir Jovic wrote:
    > James Kanze wrote:
    >>
    >> Actually, this is one. In a well designed language, bounds
    >> checking would not have such exhorbitant overhead. The way
    >> pointers and arrays work in C (and thus in C++) is a serious
    >> flaw in the language.

    >
    > This is contradiction to what you wrote above, no?
    > Above you wrote it would require a fat pointer, and here you wrote
    > that it wouldn't need big overhead. Can you explain why?


    In other languages pointers and arrays are different creatures, with
    no implicit conversion.

    In languages like Ada, an array index is often of a subtype that also
    defines the array size. That way you don't have to range check an
    array access, as the index just cannot be out of range. (At the cost
    of checking the forming of the index values, but data flow analysis
    removes a lot of that).


    Bo Persson
     
    Bo Persson, Sep 22, 2009
    #17
  18. On Sep 21, 9:24 am, (Pascal J. Bourguignon) wrote:
    > Keith H Duggar <> writes:
    > > I'm surprised that after all these years and all your education
    > > and experience that you still swallow the "pointers are evil" BS.

    >
    > Pointers as implemented by C compilers are evil indeed.
    > Checked pointers would be admissible.
    >
    > The C or C++ languages themselves says that it is illegal (or
    > technically, "undefined") to access via a pointer beyond the allocated
    > memory block. Why don't the compilers control this?


    Generally the "compiler" cannot control this but the runtime
    system can and many do (to some degree or another). For example
    that is why we might see a "segmentation fault" etc. The higher
    performance penalty you can afford to pay the more checking you
    can obtain.

    > Notice that we're talking about "classes of program working in a
    > controled environment". This is the category we're talking about.
    > Above, any occurence of "languages", must be taken as the typical
    > category in which their implementations generally fall. You may have
    > exceptionnal implementations (eg a C interpreter that controls all
    > pointer accesses, or a Common Lisp compiler without any safety
    > optimization that would let you implement buffer overflows), but we're
    > not considering these exceptional cases.
    >
    > A meeting point that could satisfy both of us (but remember that I'm
    > asserting that programs don't need to be that close to the metal, so I
    > don't really see the point), would be Modula-3, where you can define
    > SAFE or UNSAFE modules, UNSAFE modules being those that would use
    > unsafe primitives, such as random pointer computations. Typically,
    > you would have to prove formally their correctness and to intensively
    > test these unsafe modules before incoporating them in a system.
    >
    > Another meeting point would be that when I say that programs don't
    > need to be close to the metal, I'm speaking of source code, of
    > programs as written by human. If there are automatic tools that
    > compile high level code into binary code close to the metal, I don't
    > really mind (assuming the compilers are formally proved, and closely
    > checked).


    However, some of us view the "pointer" or "address" concept as a
    *good thing*. And even close to the right abstraction for a lot of
    useful work. I would like to point you to the following excerpt from
    the brilliant Alexander Stepanov:

    1. Addresses.
    STL is based on the fundamental assumption that addresses are
    good. The memory model of the C machine is the right base for the
    abstraction. Neither Lisp nor ML allow a natural address/location
    abstraction. You can implement address like thingies in them, but
    the built-in data strucutres do not based on the needed abstraction.
    Note that in Lisp one tends to stick to the built-in data-structures.
    I never seen a serious impementation of a doubly-linked lists in
    Lisp.
    (Yes, yes, I had done one myself too, but it was not serious.) As far
    as I know, the same holds true for SML. Arrays and lists can not
    be easily unified. Or at least, they are not usually unified.
    Take a look at list->vector, vector->list pair in Scheme and compare
    it
    with generic constructor in STL containers. They have to provide
    2N new conversion functions for every new data structure in the
    library.
    Clearly, they do not bother to extend the number of data structures.
    One of the things I am trying to do now is to extend the iterator
    classification to handle non-uniform memory references. (One of
    my collegues, Fred Chow, proposes to call them NUMA-iterators.) It is
    quite remarkable how the existing STL framework could be extended to
    deal with MP, cache behaviour, parallelism. But it all relies on
    addresses. Abstract addresses, but addresses nevertheless.

    taken from this post

    http://groups.google.com/group/comp.lang.functional/msg/5c4917e0ccce88be

    The subthread beginning here

    http://groups.google.com/group/comp.lang.functional/msg/3fac5f7f4649b82e

    is well worth a read particularly the Stepanov posts. Sadly the
    thread also shows what happens when a brilliant, experienced, and
    accomplished man shows up for a polite intellectual discussion and
    runs into smug vociferously ignorant Lisp jerks that disagree with
    him. His departure from the forums was a loss to all of us.

    KHD
     
    Keith H Duggar, Oct 1, 2009
    #18
  19. Keith H Duggar <> writes:

    > On Sep 21, 9:24 am, (Pascal J. Bourguignon) wrote:
    >> Another meeting point would be that when I say that programs don't
    >> need to be close to the metal, I'm speaking of source code, of
    >> programs as written by human. If there are automatic tools that
    >> compile high level code into binary code close to the metal, I don't
    >> really mind (assuming the compilers are formally proved, and closely
    >> checked).

    >
    > However, some of us view the "pointer" or "address" concept as a
    > *good thing*. And even close to the right abstraction for a lot of
    > useful work.


    That's where we differ. I agree that pointer/address is a useful
    concept in Von Neumann processors, but I consider it a low level
    device. And neither Von Neumann considered that stored program
    machine the ultimate hardware architecture. Too bad he died before he
    could finish his Von Neumann "mark 2" machine...


    > I would like to point you to the following excerpt from
    > the brilliant Alexander Stepanov:
    >
    > 1. Addresses.
    > STL is based on the fundamental assumption that addresses are
    > good. The memory model of the C machine is the right base for the
    > abstraction. Neither Lisp nor ML allow a natural address/location
    > abstraction. You can implement address like thingies in them, but
    > the built-in data strucutres do not based on the needed abstraction.
    > Note that in Lisp one tends to stick to the built-in data-structures.
    > I never seen a serious impementation of a doubly-linked lists in
    > Lisp.


    Doubly-linked lists pose no implementation problem in Lisp. They're
    implement as as serrious a ADT as you want them to be. The point is
    rather that they're not often useful. But when they're needed,
    there's no more difficulty to implement then in lisp than in C or C++.
    (Actually, thanks to the garbage collector, it's a lot more easier to
    implement circular data structures such as doubly-linked lists in lisp
    than in C or C++).



    > (Yes, yes, I had done one myself too, but it was not serious.) As far
    > as I know, the same holds true for SML. Arrays and lists can not
    > be easily unified. Or at least, they are not usually unified.
    > Take a look at list->vector, vector->list pair in Scheme and compare
    > it
    > with generic constructor in STL containers. They have to provide
    > 2N new conversion functions for every new data structure in the
    > library.
    > Clearly, they do not bother to extend the number of data structures.
    > One of the things I am trying to do now is to extend the iterator
    > classification to handle non-uniform memory references. (One of
    > my collegues, Fred Chow, proposes to call them NUMA-iterators.) It is
    > quite remarkable how the existing STL framework could be extended to
    > deal with MP, cache behaviour, parallelism. But it all relies on
    > addresses. Abstract addresses, but addresses nevertheless.


    We can implement iterators in lisp or scheme more easily than in C++,
    thanks to closures. Closures are a high level construct that allows
    to implement in an abstract way a lot of concepts for which you would
    use low level constructs such as pointers or iterators in C++.
    Perhaps that's the reason why a C++ programmer such as Alexander
    Stepanov cannot see them in lisp, he's looking too low.


    --
    __Pascal Bourguignon__
     
    Pascal J. Bourguignon, Oct 2, 2009
    #19
  20. On 2 oct, 12:02, (Pascal J. Bourguignon) wrote:
    [snip]
    > We can implement iterators in lisp or scheme more easily than in C++,
    > thanks to closures.   Closures are a high level construct that allows
    > to implement in an abstract way a lot of concepts for which you would
    > use low level constructs such as  pointers or iterators in C++.
    > Perhaps that's the reason why a C++ programmer such as Alexander
    > Stepanov cannot see them in lisp, he's looking too low.


    I suspect that it is not a matter of level of point of view. IMHO
    Stephanov aims at abstracting algorithms while closures is a
    functional/OOP artifact unifying algorithms behind a type.

    AFAIK closures are unable to adapt with the semantic of the underlying
    data while generic programs can.

    --
    Michael
     
    Michael Doubez, Oct 2, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Phil
    Replies:
    1
    Views:
    675
    llewelly
    Sep 16, 2003
  2. muser
    Replies:
    3
    Views:
    785
    Ron Natalie
    Sep 18, 2003
  3. A
    Replies:
    3
    Views:
    481
    Alan Kelon
    Oct 29, 2003
  4. Xamalek
    Replies:
    7
    Views:
    711
  5. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    739
Loading...

Share This Page