If we could do it all over again : rethinking pointer syntax

Discussion in 'C++' started by stork, Dec 18, 2006.

  1. stork

    stork Guest

    C++ is always evolving. Within C++, there tend to be two communities.
    There is the community pushing for performance features, getting ever
    closer to the metal, and then, there is the applications community.

    The applications community would, in general, prefer C++ to become more
    high level - adding things like garbage collectors, improved pointer
    safety, in short, to be a language useful for building applications
    that now go to the Java and C# and even the D crowds.

    The systems community does not want C++ to not be any of that. They
    want C++ to be good at writing Java's and C#'s and D's. They want C++
    to stick to its roots as a good systems language, where we can build
    libraries to build applications with, if we choose. To them, a 64k
    application is still a worthy goal for the sake of fitting into 64k.

    The thought has occurred to me that the systems crowd will ultimately
    lose. More people want applications and generally speaking, trading a
    bit of performance to gain safety or ease of use has produced good
    results. But that leaves us systems people in need of a C/C++ for
    systems.

    So, with the idea in mind that C++ may well fork, or, some other
    systems language will be needed to fill a hacker void, then, one must
    attend to the subject of pointers. Applications people often loath
    pointers - indeed, other applications languages simply do not have
    them. On the other hand, systems people love pointers. So, any future
    systems language will have to have pointers.

    And that really begs the question, can the pointer be improved? For
    me, the *dereference or element->node syntax is troublesome becuase it
    complicates the use of templates. You either need to have special
    accessors, wrap things up in references, and so on. What if, the
    *dereference was actually implied with a pointer, such that:

    char *test = "foo";

    printf( "%c", test );

    would yield "f" as its output.

    iterating a pointer could still work by array index. The relationship

    test[0] == test

    would always work for pointer types, assuming test was in the same
    spot.

    I've thought about the idea of always making everything a pointer, as
    is the case in Java or C#, but, that has its own problems.

    Thoughts? I already know I'm crazy.
     
    stork, Dec 18, 2006
    #1
    1. Advertising

  2. stork

    Guest

    stork wrote:
    > C++ is always evolving. Within C++, there tend to be two communities.
    > There is the community pushing for performance features, getting ever
    > closer to the metal, and then, there is the applications community.
    >
    > The applications community would, in general, prefer C++ to become more
    > high level - adding things like garbage collectors, improved pointer
    > safety, in short, to be a language useful for building applications
    > that now go to the Java and C# and even the D crowds.
    >
    > The systems community does not want C++ to not be any of that. They
    > want C++ to be good at writing Java's and C#'s and D's. They want C++
    > to stick to its roots as a good systems language, where we can build
    > libraries to build applications with, if we choose. To them, a 64k
    > application is still a worthy goal for the sake of fitting into 64k.
    >
    > The thought has occurred to me that the systems crowd will ultimately
    > lose. More people want applications and generally speaking, trading a
    > bit of performance to gain safety or ease of use has produced good
    > results. But that leaves us systems people in need of a C/C++ for
    > systems.
    >
    > So, with the idea in mind that C++ may well fork, or, some other
    > systems language will be needed to fill a hacker void, then, one must
    > attend to the subject of pointers. Applications people often loath
    > pointers - indeed, other applications languages simply do not have
    > them. On the other hand, systems people love pointers. So, any future
    > systems language will have to have pointers.
    >
    > And that really begs the question, can the pointer be improved? For
    > me, the *dereference or element->node syntax is troublesome becuase it
    > complicates the use of templates. You either need to have special
    > accessors, wrap things up in references, and so on. What if, the
    > *dereference was actually implied with a pointer, such that:
    >
    > char *test = "foo";
    >
    > printf( "%c", test );
    >
    > would yield "f" as its output.
    >
    > iterating a pointer could still work by array index. The relationship
    >
    > test[0] == test
    >
    > would always work for pointer types, assuming test was in the same
    > spot.
    >
    > I've thought about the idea of always making everything a pointer, as
    > is the case in Java or C#, but, that has its own problems.
    >
    > Thoughts? I already know I'm crazy.


    I don't get it. If so many applications programmers can't wrap their
    heads around C++, or simply don't think it's the right tool for the
    job, why don't they simply switch to another language? The idea that
    C++ will 'become something more high level' is somewhat ludicrous when
    there are already other 'more high level' languages out there.
     
    , Dec 18, 2006
    #2
    1. Advertising

  3. stork

    Noah Roberts Guest

    wrote:

    > I don't get it. If so many applications programmers can't wrap their
    > heads around C++, or simply don't think it's the right tool for the
    > job, why don't they simply switch to another language?


    Because this is all meaningless conjecture.

    > The idea that
    > C++ will 'become something more high level' is somewhat ludicrous when
    > there are already other 'more high level' languages out there.


    On the other hand, there has been a "fork". Interestingly it was
    created so that application programmers *could* have pointers and all
    the "bad" things that C++ has. I can't imagine a lot of systems
    programming takes place in .net.
     
    Noah Roberts, Dec 18, 2006
    #3
  4. stork

    Joe Seigh Guest

    stork wrote:
    > C++ is always evolving. Within C++, there tend to be two communities.
    > There is the community pushing for performance features, getting ever
    > closer to the metal, and then, there is the applications community.
    >
    > The applications community would, in general, prefer C++ to become more
    > high level - adding things like garbage collectors, improved pointer
    > safety, in short, to be a language useful for building applications
    > that now go to the Java and C# and even the D crowds.

    [...]
    >
    > So, with the idea in mind that C++ may well fork, or, some other
    > systems language will be needed to fill a hacker void, then, one must
    > attend to the subject of pointers. Applications people often loath
    > pointers - indeed, other applications languages simply do not have
    > them. On the other hand, systems people love pointers. So, any future
    > systems language will have to have pointers.
    >
    > And that really begs the question, can the pointer be improved? For
    > me, the *dereference or element->node syntax is troublesome becuase it
    > complicates the use of templates. You either need to have special
    > accessors, wrap things up in references, and so on.


    [...]

    C++ could use better pointer abstraction so that using smart pointers
    would be less awkward.

    Some sort of way of overriding the casting operator for (void *) and
    (char *) so you could use smart pointers where regular pointers were
    used. I tried this once but ran into various kinds of problems, some
    of which may have been caused by a non compliant compiler.

    Also some way of forbiding assignment of the raw pointer value to void*
    or char* to prevent uncontrolled usage of that value.

    And some kind of attribute on methods so the compiler could optimize
    the results of methods that were idempotent as long as no methods that
    modified the object were called. You'd want this to make up for not
    being able to optimize by explicitly assigning the raw pointer value
    to a variable.

    This would go a long way to making smart pointers look a lot like
    regular pointers.

    There's also some issues with new and delete being in the wrong place
    but I've mentioned that before.


    --
    Joe Seigh

    When you get lemons, you make lemonade.
    When you get hardware, you make software.
     
    Joe Seigh, Dec 18, 2006
    #4
  5. stork

    stork Guest

    Stork replied to:

    > There's also some issues with new and delete being in the wrong place
    > but I've mentioned that before.


    Actually, for my benefit, can you either expound or provide a link?
     
    stork, Dec 18, 2006
    #5
  6. stork

    Joe Seigh Guest

    stork wrote:
    > Stork replied to:
    >
    >
    >>There's also some issues with new and delete being in the wrong place
    >>but I've mentioned that before.

    >
    >
    > Actually, for my benefit, can you either expound or provide a link?
    >


    Usually you want the smart pointer to control allocation and decallocation
    since that's what smart pointers do, manage memory. The way it's done
    now is problematic. You have problems with raw objects being assigned to
    two separate smart pointers when it should have been only one and then
    just smart pointer copying after that. Or you have to create a derived class
    to override new and delete for things like intrusive reference counting.
    Except the derived class can't be used transparantly as the class it was
    based on. Making new and delete virtual would work somewhat but it would
    be better to make them virtual methods for the smart pointers so that
    different allocation policies could interoperate, e.g. using objects that
    come from different alocation pools but are otherwise identical.



    --
    Joe Seigh

    When you get lemons, you make lemonade.
    When you get hardware, you make software.
     
    Joe Seigh, Dec 18, 2006
    #6
  7. stork wrote:

    > C++ is always evolving. Within C++, there tend to be two communities.
    > There is the community pushing for performance features, getting ever
    > closer to the metal, and then, there is the applications community.
    >
    > The applications community would, in general, prefer C++ to become more
    > high level - adding things like garbage collectors, improved pointer
    > safety,


    You can do all of that in C++. It's just not built in.

    > in short, to be a language useful for building applications
    > that now go to the Java and C# and even the D crowds.


    But C++ is already useful for building those sorts of applications. I
    forever find myself returning to it when a higher-level utopia has lost
    its lustre. In fact, I find that a great many of the applications I
    depend on most are written in C++, even though modern higher-level
    alternatives were available; and I don't think the choice was generally
    made from habit alone.

    > The systems community does not want C++ to not be any of that. They
    > want C++ to be good at writing Java's and C#'s and D's. They want C++
    > to stick to its roots as a good systems language, where we can build
    > libraries to build applications with, if we choose. To them, a 64k
    > application is still a worthy goal for the sake of fitting into 64k.
    >
    > The thought has occurred to me that the systems crowd will ultimately
    > lose.


    Why? Are you assuming that the language itself will be changed in a way
    that the "systems crowd" won't want to use it any more? I doubt that
    will happen any time soon, if ever, but even if it did, I think
    compilers for the old C++ would remain available and used -- see
    Fortran.

    > More people want applications and generally speaking, trading a
    > bit of performance to gain safety or ease of use has produced good
    > results. But that leaves us systems people in need of a C/C++ for
    > systems.
    >
    > So, with the idea in mind that C++ may well fork, or, some other
    > systems language will be needed to fill a hacker void, then, one must
    > attend to the subject of pointers. Applications people often loath
    > pointers -


    Silly people.

    > indeed, other applications languages simply do not have
    > them. On the other hand, systems people love pointers.


    Well -- I wouldn't go quite *that* far.

    > So, any future
    > systems language will have to have pointers.
    >
    > And that really begs the question, can the pointer be improved?


    For some things, yes. And so the reference was invented.

    > For
    > me, the *dereference or element->node syntax is troublesome becuase it
    > complicates the use of templates. You either need to have special
    > accessors, wrap things up in references, and so on. What if, the
    > *dereference was actually implied with a pointer, such that:


    Because then you couldn't do direct pointer manipulation any more -- or
    am I not getting what you're saying?

    The current syntax has the advantage that you always know when you're
    working with a pointer, and if you don't, the compiler will generally
    hit you over the head. A reference doesn't have that syntax, because it
    doesn't need it; it really is a "safe pointer".

    And speaking of references, how does your proposal improve on or
    complement them?

    >
    > char *test = "foo";
    >
    > printf( "%c", test );
    >
    > would yield "f" as its output.
    >
    > iterating a pointer could still work by array index. The relationship
    >
    > test[0] == test
    >
    > would always work for pointer types, assuming test was in the same
    > spot.


    This smells like syntactic quicksand to me.

    > I've thought about the idea of always making everything a pointer, as
    > is the case in Java or C#, but, that has its own problems.


    It certainly does. That *would* all but destroy C++'s usefulness as a
    low-level language.

    --mpa
     
    Michael Ashton, Dec 18, 2006
    #7
    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. Magnus Lycka

    Rethinking the Python tutorial

    Magnus Lycka, Feb 9, 2006, in forum: Python
    Replies:
    11
    Views:
    541
    Magnus Lycka
    Feb 15, 2006
  2. dorayme
    Replies:
    0
    Views:
    379
    dorayme
    May 4, 2008
  3. Steven D'Aprano
    Replies:
    138
    Views:
    1,997
  4. James Edward Gray II

    Rethinking Memoization

    James Edward Gray II, Jan 24, 2006, in forum: Ruby
    Replies:
    8
    Views:
    156
    Robert Klemme
    Jan 27, 2006
  5. John Carter
    Replies:
    3
    Views:
    499
    Robert Klemme
    Mar 30, 2007
Loading...

Share This Page