Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > If we could do it all over again : rethinking pointer syntax

Reply
Thread Tools

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

 
 
stork
Guest
Posts: n/a
 
      12-18-2006
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.

 
Reply With Quote
 
 
 
 
jjds101@yahoo.com
Guest
Posts: n/a
 
      12-18-2006

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.

 
Reply With Quote
 
 
 
 
Noah Roberts
Guest
Posts: n/a
 
      12-18-2006

(E-Mail Removed) 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.

 
Reply With Quote
 
Joe Seigh
Guest
Posts: n/a
 
      12-18-2006
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.
 
Reply With Quote
 
stork
Guest
Posts: n/a
 
      12-18-2006
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?

 
Reply With Quote
 
Joe Seigh
Guest
Posts: n/a
 
      12-18-2006
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.
 
Reply With Quote
 
Michael Ashton
Guest
Posts: n/a
 
      12-18-2006

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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
server not found, try again over and over again- help Bill Penney Firefox 1 07-31-2011 08:10 AM
Re: Rethinking My Use of Modal Windows.... dorayme HTML 0 05-03-2008 11:12 PM
VOIP over VPN over TCP over WAP over 3G Theo Markettos UK VOIP 2 02-14-2008 03:27 PM
Rethinking the Python tutorial Magnus Lycka Python 11 02-15-2006 12:41 PM
Rethinking Canon 28-135 to 24-70 f2.8L Bill Digital Photography 31 06-12-2004 01:18 AM



Advertisments