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

[stork]

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.

[jjds101]

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.

[Noah Roberts]

[e-mail] 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.

[Joe Seigh]

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.

[stork]

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?

[Joe Seigh]

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.

[Michael Ashton]

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