Is pointer programming even necessary?

[Alf P. Steinbach]

* (e-mail address removed):

Exactly what was it that Alf (who is indeed one of them most
knowledgeable and courteous posters on c.l.c++) wrote was disproved by
your few minutes of web surfing?

Well, to mix metaphors, I can sometimes, quite unintentionally, due to the
optimized connection from brain to mouth, or in this case, fingers, be an
elephant in a glasshouse.

I just hope as few as possible take that as serious attempts at offense.

It would ruin my earlier reputation (in some Norwegian "frustration"-groups) as
Master Of Offense (MOO(TM)).


Cheers,

- Alf

 

[James Kanze]

* Danno:

I think you mean "pointer arithmetic", because Java certainly
have pointers. Java reference values are pointers. They're
called pointers by the Java language definition (just consider
what the heck you think a Java NullPointerException is all
about), and they act like pointers.

Presumably, again, pointer arithmetic.

Presumably, again, pointer arithmetic.

Well, pointer arithmetic is necessary to build the foundations
of languages such as Java.

At a lower level. In practice, even in C++ (at least at the
application level), I tend to pretend that it doesn't exist, and
think of expressions like a much as I would in Java.

Any indexing operation or object field access reduces at a
lower level to pointer arithmetic.

Yep, but that's the compiler writers problem, not mine.

Like you, I don't really understand the question, since I tend
to use pointers (and thus "pointer logic") a lot more in Java
than I do in C++. My impression is he's got it backwards, that
you have to concern yourself with "pointer logic" (e.g.
reference semantics, new, etc.) a lot more in Java, even when
logically, the problem doesn't call for it (e.g. an array of
complex).

 

[James Kanze]

Do those languages offer the versatility of iterator-based
generic algorithms? Can you, for example, use the exact same
function to sort an array of integers and a double-ended queue
of floats? Can you, for example, use the exact same function
to iterate through an array of chars, a list of complex
numbers or a balanced binary tree containing your own type of
objects, and have to function return the sum of all the
elements? Can you create your own innovative data container
and have those exact same functions perform those operations
on it?

Ok, granted, I don't know if you can do that with Ruby. I know
you can't do that with Java.

I don't know about Ruby, but I know that this sort of thing is
no problem with Java---for most everyday jobs like this, in
fact, the Java collections library (and especially the concept
of iterators in Java) is far superior to the STL.

 

[Juha Nieminen]

Why not? Java can

I don't believe you can use the same function to sort an array of
integers and, for example, an array of strings.

And by "array" I mean the [] type array, and by "integer" I mean
integer, not some class.

 

[Juha Nieminen]

Sure you can..All iterators in java are generic.

Show me the code that sorts an array of integers and, for example, an
array of strings in Java. And "array" means the [] arrays and "integer"
means integer, not some class.

 

[Juha Nieminen]

I don't know about Ruby, but I know that this sort of thing is
no problem with Java

How exactly does it succeed in doing that? AFAIK Java generics do not
support basic types, such as integers and floats, nor can you create
pointers to arrays.

If Java generics have added support for basic types and creating
iterators from arrays lately then I stand corrected.

 

[James Kanze]

How exactly does it succeed in doing that? AFAIK Java generics
do not support basic types, such as integers and floats,

That's a different problem. The "basic types" in Java are
second class citizens, and you can't have collections of them
without boxing. (I've not kept up to date with Java, but
logically, the generic stuff they added should handle automatic
boxing.) It's a problem with the basic language, not with the
Java collections.

 

[Danno]

How exactly does it succeed in doing that? AFAIK Java generics do not
support basic types, such as integers and floats, nor can you create
pointers to arrays.

Well, it is a C++ group, but why not.

You can most definitely use generics with integers and floats, and
with autoboxing it's a breeze.

List<Integer> list = new ArrayList<Integer>();
list.add(1);
list.add(5);
......
List<Float> list2 = new ArrayList<Float>();
list2.add(1.5f);
list2.add(5.4f);

Pointers to arrays is......is.....well, let me describe with code.

Since object variables hold object references and not object values.

int[] values = new int[10];

values is actually referencing the array

therefore..

values2 = values;
values2[3] = 4;
assert values[3] == 4; //true

 

[Danno]

Hence the answer to the question "is pointer programming even
necessary?". Maybe not absolutely necessary, but allows doing things
like this.

I got my answer. I forgot that in C++, object variables hold object
values. Pointers and references are not handled for you in C++ like
they are in java and ruby.

 

[Juha Nieminen]

That's a different problem. The "basic types" in Java are
second class citizens, and you can't have collections of them
without boxing. (I've not kept up to date with Java, but
logically, the generic stuff they added should handle automatic
boxing.) It's a problem with the basic language, not with the
Java collections.

Hence the answer to the question "is pointer programming even
necessary?". Maybe not absolutely necessary, but allows doing things
like this.

 

[Juha Nieminen]

You can most definitely use generics with integers and floats, and
with autoboxing it's a breeze.

List<Integer> list = new ArrayList<Integer>();

That's not an integer. That's a class.

List<Float> list2 = new ArrayList<Float>();

Neither is that a float, but also a class.

 

[Danno]

That's not an integer. That's a class.


Neither is that a float, but also a class.

Ooops should've caps on the Integers and Floats. That is right.
There are no generics for 'primitive' types, but with the autoboxing
between the primitive and objects you can still use the generic
collection type.

 

[James Kanze]

Hence the answer to the question "is pointer programming even
necessary?". Maybe not absolutely necessary, but allows doing
things like this.

I don't see the relationship.

Formally, in C++, an expression like a involves pointer
arithmetic (or more often, an overloaded operator).
Practically, at the application level, you should probably
program as if it were a true indexing operator (i.e. as it is in
Java), and forget that pointer arithmetic even exists. In fact,
at the application level, it should be fairly rare to use
something like a except with an overloaded [] (in which case,
formally, it's a function call, not pointer arithmetic).

Obviously, if you're implementing something like std::vector<>,
you'll probably need to deal with pointer arithmetic. Just as
you would if you were implementing the array operations in a
JVM. But you don't usually need to do so, and if you do, you're
doing something that you cannot do at all in Java, so the
comparison doesn't apply.

More generally, of course, pointer programming (as opposed to
just pointer arithmetic) is essential in both languages: in C++,
any time you have an object whose lifetime doesn't correspond to
a scope, or an object for which the number or types of
sub-objects isn't know until runtime, and in Java, any time you
have an object (or an array, since arrays are also objects).
The most characteristic operator involved in pointer
programming is the new operator, and my experience is that I use
it a lot more often in Java than in C++.

 

[ppi]

I have decided that this year, I will refresh my C++ skills since they
are old and brittle. I have moved onto other languages over the past
10-15 years or so, and all the languages I have taken to don't have
the pointer logic associated with it (Java, Ruby, etc). I can't say
that I missed it. So my question is simple, is pointer programming
still viable or even necessary?

Yep they are ;-)

They are not necessary or wanted (at least with their C/C++ meaning)
in Java, ruby and other languages with automatic memory management or
garbage collection since they provide you with a raw handle to memory.
In these languages such abstraction is not necessary (or wanted) and
does not fit with the other languages abstraction provided to you.
But with languages like C and C++, you do manage the memory yourself
(deterministic memory management: you know when memory is freed),
pointers are mandatory and natural since they are abstraction provided
by these languages to access this memory (pointers arithmetics are
just a consequence of that: to iterate through memory).

They are still necessary and probably will always be there, lurking in
the corners. In Java almost everything is pointer/reference and we do
manipulate them every time we access/use objects.
People tend to think that pointers == self memory management, but no
this is no the case. This is due to the extensive use of C and
assembly (where they are a natural abstraction), so when one talk
about pointers, they think of pointers the way they are used/defined
in these languages.
C/C++ provide the programmer with all operations you would expect on
pointers: referencing (access), arithmetic (iterators operation), life-
time (you create/destroy their associated content)
On dynamic languages, Java etc. you are always provided with pointers,
but only with the referencing part, other uses are out of your reach.

On a more practical point of view, every memory intensive application
is best programmed using pointers (as used in C/C++) because you can
map the life-time of your objects directly to memory (once again this
is just because they are in that case the best abstraction for this
purpose).

So yeah, do not expect them to go away anytime soon ;-)

hope it will help,
-- paulo

 

[Danno]

Yep they are ;-)

They are not necessary or wanted (at least with their C/C++ meaning)
in Java, ruby and other languages with automatic memory management or
garbage collection since they provide you with a raw handle to memory.
In these languages such abstraction is not necessary (or wanted) and
does not fit with the other languages abstraction provided to you.
But with languages like C and C++, you do manage the memory yourself
(deterministic memory management: you know when memory is freed),
pointers are mandatory and natural since they are abstraction provided
by these languages to access this memory (pointers arithmetics are
just a consequence of that: to iterate through memory).

They are still necessary and probably will always be there, lurking in
the corners. In Java almost everything is pointer/reference and we do
manipulate them every time we access/use objects.
People tend to think that pointers == self memory management, but no
this is no the case. This is due to the extensive use of C and
assembly (where they are a natural abstraction), so when one talk
about pointers, they think of pointers the way they are used/defined
in these languages.
C/C++ provide the programmer with all operations you would expect on
pointers: referencing (access), arithmetic (iterators operation), life-
time (you create/destroy their associated content)
On dynamic languages, Java etc. you are always provided with pointers,
but only with the referencing part, other uses are out of your reach.

On a more practical point of view, every memory intensive application
is best programmed using pointers (as used in C/C++) because you can
map the life-time of your objects directly to memory (once again this
is just because they are in that case the best abstraction for this
purpose).

So yeah, do not expect them to go away anytime soon ;-)

hope it will help,
-- paulo

Five star response, Thanks.