S
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.
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.