pointers

[mikethebike]

Hi
why needs C++ pointers while f. ex. VB.NET doesn't make use of such?

In other words why does VB.NET not need pointers?

Thanks
Michael

 

[Ian Collins]

Hi
why needs C++ pointers while f. ex. VB.NET doesn't make use of such?

Because it can works with raw memory (or memory mapped devices).

In other words why does VB.NET not need pointers?

Because it can't work with raw memory.

 

[Pascal J. Bourguignon]

Because it can works with raw memory (or memory mapped devices).


Because it can't work with raw memory.

VB.NET also work with memory. And AFAIK, it's as raw as for any
program.

Perhaps you want to mean that C allow you to implement all kinds of
bugs, while VB.NET prevents you to implement whole classes of bugs?


When you write "raw memory work" you actually mean "bug provoking
memory work".


PS: VB.NET being taken here as a prototype for any class of program
working in a controled environment, such as java, ruby, perl,
python, lisp, haskell, ocaml, etc.

 

[Ian Collins]

VB.NET also work with memory. And AFAIK, it's as raw as for any
program.

Perhaps you want to mean that C allow you to implement all kinds of
bugs, while VB.NET prevents you to implement whole classes of bugs?

Oh, so device drivers are a class of bug? I'd better stop writing them
then!

PS: VB.NET being taken here as a prototype for any class of program
working in a controled environment, such as java, ruby, perl,
python, lisp, haskell, ocaml, etc.

None of which are much use for the close to the metal programming a lot
of us enjoy.

 

[Pascal J. Bourguignon]

Oh, so device drivers are a class of bug? I'd better stop writing
them then!


None of which are much use for the close to the metal programming a
lot of us enjoy.

I don't say anything for programs that really need to be close to the
metal. The problem is that 99% of the programs written in C or C++
have no need to be that close to the metal, and should rather be
written in other languages.


kernel.org be written in C, ok. Anything on sourceforge.net written
in C or C++ is almost certainly language mismatch.

 

[Keith H Duggar]

I don't say anything for programs that really need to be close to the

Wrong. You said "for any program". And whether or not you PS note
actually applied to that initial outburst is entirely unclear.

metal. The problem is that 99% of the programs written in C or C++
have no need to be that close to the metal, and should rather be
written in other languages.

So your initial "AFAIK, it's as raw as for any program" was wrong?

kernel.org be written in C, ok. Anything on sourceforge.net written
in C or C++ is almost certainly language mismatch.

Which is clearly a VERY different message from your first post.
I guess you a backtracking a bit now that your original over-
zealous bluster was called.

I'm surprised that after all these years and all your education
and experience that you still swallow the "pointers are evil" BS.

KHD

 

[Pascal J. Bourguignon]

Wrong. You said "for any program". And whether or not you PS note
actually applied to that initial outburst is entirely unclear.

If I'm saying the tautology:

for any integer x, ((x<0) and (x>0)) ==> (x=sqrt(x+1))

and you cannot find any integer such as x=sqrt(x+1), then it means
that there is no integer x such as (x<0) and (x>0).


Analoguously, there is no program that really need to be close to the
metal. This is exactly what I'm saying.

So your initial "AFAIK, it's as raw as for any program" was wrong?


Which is clearly a VERY different message from your first post.
I guess you a backtracking a bit now that your original over-
zealous bluster was called.

It may look like I'm backtracking, but it's only a concession to the
vicious circle constituted by unix<=>C.

I admit that you write a unix kernel and its driver in C, because I
let the definition of unix to be a kernel written in C.


But doing this concession, I require that you do the concession that
anything else mustn't be written in C.


And I say nothing about the bugs inherent in implementing a kernel in
C. I'll only say that I'd prefer to work on a kernel NOT implemented
in C, for example, a kernel with drivers implemented in Lisp, such as
the Lisp Machine kernel, (or Movitz for a modern example). But other
programming languages are also admissible, such as Oberon or Modula-3.

I'm surprised that after all these years and all your education
and experience that you still swallow the "pointers are evil" BS.

Pointers as implemented by C compilers are evil indeed.
Checked pointers would be admissible.

The C or C++ languages themselves says that it is illegal (or
technically, "undefined") to access via a pointer beyond the allocated
memory block. Why don't the compilers control this?


Notice that we're talking about "classes of program working in a
controled environment". This is the category we're talking about.
Above, any occurence of "languages", must be taken as the typical
category in which their implementations generally fall. You may have
exceptionnal implementations (eg a C interpreter that controls all
pointer accesses, or a Common Lisp compiler without any safety
optimization that would let you implement buffer overflows), but we're
not considering these exceptional cases.


A meeting point that could satisfy both of us (but remember that I'm
asserting that programs don't need to be that close to the metal, so I
don't really see the point), would be Modula-3, where you can define
SAFE or UNSAFE modules, UNSAFE modules being those that would use
unsafe primitives, such as random pointer computations. Typically,
you would have to prove formally their correctness and to intensively
test these unsafe modules before incoporating them in a system.

Another meeting point would be that when I say that programs don't
need to be close to the metal, I'm speaking of source code, of
programs as written by human. If there are automatic tools that
compile high level code into binary code close to the metal, I don't
really mind (assuming the compilers are formally proved, and closely
checked).

 

[Pascal J. Bourguignon]

It may look like I'm backtracking, but it's only a concession to the
vicious circle constituted by unix<=>C.

I must say that there's another vicious circle under unix, which is
that of the kind of processors we have, and this is probably the worst
of the two.

Since unix developed, processors evolved to fulfill the needs of unix,
and unix adapted to match well these processors. The end of this
co-evolution is the ix86 Intel processor. :-(

(Notice that the PDP-11 processor was little endian, and that all
big-endian processors have been droped in favor of a little endian
one for running the majority of unix systems).


The evilness of this vicious circle, is that you will be comparing the
performance of other systems and languages as implemented on
processors optimized for unix and C, instead of comparing it on
processors that would have evolved on other branches, optimized for
other kinds of systems and languages.

Notice that C programs compiled with the Zeta-C compiler running on
Lisp Machine weren't faster than Lisp programs compiled on that system
(just to take an example I have in mind, there were other examples).



Nowadays, it seems to me we have computers fast enough that we could
stepback and rethink a little the global architecture of our computer,
and try something else.

If Apple can lose cycles to have jumping icons, couldn't we lose some
cycles to have safer and smarter software?

 

[Richard Herring]

In message

Hi
why needs C++ pointers while f. ex. VB.NET doesn't make use of such?

In other words why does VB.NET not need pointers?

It _does_ need pointers. What do you think is happening here?

Dim x As Object
x = New MyType()

VB's "reference-type variables" are just pointers by another name.

 

[joseph cook]

The C or C++ languages themselves says that it is illegal (or
technically, "undefined") to access via a pointer beyond the allocated
memory block.  Why don't the compilers control this?

What? Control it exactly how? If I have a library API call that
returns the address of say, a shared memory buffer, how exactly is
this supposed to be flagged by a compiler?

I suspect there are millions of intellegent critiques of C and C++,
but you haven't found one yet.

Your question is equivalant to asking why when I run an executable on
a different machine with less memory, why the compiler doesn't flag
that and throw a warning if there isn't enough space. Of course, I
may not even have a compiler installed on my new machine, but why
should that stop it?

Joe C

 

[Bo Persson]

VB.NET also work with memory. And AFAIK, it's as raw as for any
program.

Perhaps you want to mean that C allow you to implement all kinds of
bugs, while VB.NET prevents you to implement whole classes of bugs?

Nobody is forcing you to use pointers. If you can write better
programs without them, why don't you just do that?

The language also contains goto, which allows you to write horrible
spaghetti-style programs. Most people don't.


Bo Persson

 

[James Kanze]

On Sep 21, 9:24 am, (e-mail address removed) (Pascal J. Bourguignon) wrote:

What? Control it exactly how? If I have a library API call
that returns the address of say, a shared memory buffer, how
exactly is this supposed to be flagged by a compiler?

The C (and C++) standard was carefully written to make such
implementations possible, and they have existed (and maybe still
do). Catching such errors, however, does require "fat"
pointers, which have significant performance overhead.

I suspect there are millions of intellegent critiques of C and
C++, but you haven't found one yet.

Actually, this is one. In a well designed language, bounds
checking would not have such exhorbitant overhead. The way
pointers and arrays work in C (and thus in C++) is a serious
flaw in the language.

 

[James Kanze]

Pascal J. Bourguignon wrote:

Nobody is forcing you to use pointers. If you can write better
programs without them, why don't you just do that?

You need pointers at some level, in order to implement dynamic
data structures, and to navigate between objects.

The language also contains goto, which allows you to write
horrible spaghetti-style programs. Most people don't.

There are two major sources of bugs regarding pointers. The
first is due to pointer arithmetic and the lack of bounds
checking. If you're implementing something like std::vector,
you can't avoid it; otherwise, you should be using something
like std::vector, which can eliminate an entire class of errors.
The second is using pointers to objects which no longer exist;
this can be detected by means of some sort of garbage collection
(which means that the memory for an object cannot be recycled as
long as a pointer to that object exists), but only partially,
since it can't affect pointers to objects not allocated
dynamically.

 

[Vladimir Jovic]

The C (and C++) standard was carefully written to make such
implementations possible, and they have existed (and maybe still
do). Catching such errors, however, does require "fat"
pointers, which have significant performance overhead.


Actually, this is one. In a well designed language, bounds
checking would not have such exhorbitant overhead. The way
pointers and arrays work in C (and thus in C++) is a serious
flaw in the language.

This is contradiction to what you wrote above, no?
Above you wrote it would require a fat pointer, and here you wrote that
it wouldn't need big overhead. Can you explain why?

 

[Krice]

The way pointers and arrays work in C (and thus in C++) is
a serious flaw in the language.

I thought they work perfectly if used properly.

 

[James Kanze]

This is contradiction to what you wrote above, no?
No.

Above you wrote it would require a fat pointer, and here you
wrote that it wouldn't need big overhead. Can you explain why?

Above I wrote that in C or C++ it would require a fat pointer.
In a well designed language, this wouldn't necessarily be the
case; the fat pointer is required because C and C++ don't
distinguish between a pointer to a single object, and a pointer
to the first element of an array.

 

[Bo Persson]

This is contradiction to what you wrote above, no?
Above you wrote it would require a fat pointer, and here you wrote
that it wouldn't need big overhead. Can you explain why?

In other languages pointers and arrays are different creatures, with
no implicit conversion.

In languages like Ada, an array index is often of a subtype that also
defines the array size. That way you don't have to range check an
array access, as the index just cannot be out of range. (At the cost
of checking the forming of the index values, but data flow analysis
removes a lot of that).


Bo Persson

 

[Keith H Duggar]

Pointers as implemented by C compilers are evil indeed.
Checked pointers would be admissible.

The C or C++ languages themselves says that it is illegal (or
technically, "undefined") to access via a pointer beyond the allocated
memory block. Why don't the compilers control this?

Generally the "compiler" cannot control this but the runtime
system can and many do (to some degree or another). For example
that is why we might see a "segmentation fault" etc. The higher
performance penalty you can afford to pay the more checking you
can obtain.

Notice that we're talking about "classes of program working in a
controled environment". This is the category we're talking about.
Above, any occurence of "languages", must be taken as the typical
category in which their implementations generally fall. You may have
exceptionnal implementations (eg a C interpreter that controls all
pointer accesses, or a Common Lisp compiler without any safety
optimization that would let you implement buffer overflows), but we're
not considering these exceptional cases.

A meeting point that could satisfy both of us (but remember that I'm
asserting that programs don't need to be that close to the metal, so I
don't really see the point), would be Modula-3, where you can define
SAFE or UNSAFE modules, UNSAFE modules being those that would use
unsafe primitives, such as random pointer computations. Typically,
you would have to prove formally their correctness and to intensively
test these unsafe modules before incoporating them in a system.

Another meeting point would be that when I say that programs don't
need to be close to the metal, I'm speaking of source code, of
programs as written by human. If there are automatic tools that
compile high level code into binary code close to the metal, I don't
really mind (assuming the compilers are formally proved, and closely
checked).

However, some of us view the "pointer" or "address" concept as a
*good thing*. And even close to the right abstraction for a lot of
useful work. I would like to point you to the following excerpt from
the brilliant Alexander Stepanov:

1. Addresses.
STL is based on the fundamental assumption that addresses are
good. The memory model of the C machine is the right base for the
abstraction. Neither Lisp nor ML allow a natural address/location
abstraction. You can implement address like thingies in them, but
the built-in data strucutres do not based on the needed abstraction.
Note that in Lisp one tends to stick to the built-in data-structures.
I never seen a serious impementation of a doubly-linked lists in
Lisp.
(Yes, yes, I had done one myself too, but it was not serious.) As far
as I know, the same holds true for SML. Arrays and lists can not
be easily unified. Or at least, they are not usually unified.
Take a look at list->vector, vector->list pair in Scheme and compare
it
with generic constructor in STL containers. They have to provide
2N new conversion functions for every new data structure in the
library.
Clearly, they do not bother to extend the number of data structures.
One of the things I am trying to do now is to extend the iterator
classification to handle non-uniform memory references. (One of
my collegues, Fred Chow, proposes to call them NUMA-iterators.) It is
quite remarkable how the existing STL framework could be extended to
deal with MP, cache behaviour, parallelism. But it all relies on
addresses. Abstract addresses, but addresses nevertheless.

taken from this post

http://groups.google.com/group/comp.lang.functional/msg/5c4917e0ccce88be

The subthread beginning here

http://groups.google.com/group/comp.lang.functional/msg/3fac5f7f4649b82e

is well worth a read particularly the Stepanov posts. Sadly the
thread also shows what happens when a brilliant, experienced, and
accomplished man shows up for a polite intellectual discussion and
runs into smug vociferously ignorant Lisp jerks that disagree with
him. His departure from the forums was a loss to all of us.

KHD

 

[Pascal J. Bourguignon]

However, some of us view the "pointer" or "address" concept as a
*good thing*. And even close to the right abstraction for a lot of
useful work.

That's where we differ. I agree that pointer/address is a useful
concept in Von Neumann processors, but I consider it a low level
device. And neither Von Neumann considered that stored program
machine the ultimate hardware architecture. Too bad he died before he
could finish his Von Neumann "mark 2" machine...

I would like to point you to the following excerpt from
the brilliant Alexander Stepanov:

1. Addresses.
STL is based on the fundamental assumption that addresses are
good. The memory model of the C machine is the right base for the
abstraction. Neither Lisp nor ML allow a natural address/location
abstraction. You can implement address like thingies in them, but
the built-in data strucutres do not based on the needed abstraction.
Note that in Lisp one tends to stick to the built-in data-structures.
I never seen a serious impementation of a doubly-linked lists in
Lisp.

Doubly-linked lists pose no implementation problem in Lisp. They're
implement as as serrious a ADT as you want them to be. The point is
rather that they're not often useful. But when they're needed,
there's no more difficulty to implement then in lisp than in C or C++.
(Actually, thanks to the garbage collector, it's a lot more easier to
implement circular data structures such as doubly-linked lists in lisp
than in C or C++).

(Yes, yes, I had done one myself too, but it was not serious.) As far
as I know, the same holds true for SML. Arrays and lists can not
be easily unified. Or at least, they are not usually unified.
Take a look at list->vector, vector->list pair in Scheme and compare
it
with generic constructor in STL containers. They have to provide
2N new conversion functions for every new data structure in the
library.
Clearly, they do not bother to extend the number of data structures.
One of the things I am trying to do now is to extend the iterator
classification to handle non-uniform memory references. (One of
my collegues, Fred Chow, proposes to call them NUMA-iterators.) It is
quite remarkable how the existing STL framework could be extended to
deal with MP, cache behaviour, parallelism. But it all relies on
addresses. Abstract addresses, but addresses nevertheless.

We can implement iterators in lisp or scheme more easily than in C++,
thanks to closures. Closures are a high level construct that allows
to implement in an abstract way a lot of concepts for which you would
use low level constructs such as pointers or iterators in C++.
Perhaps that's the reason why a C++ programmer such as Alexander
Stepanov cannot see them in lisp, he's looking too low.

 

[Michael Doubez]

On 2 oct, 12:02, (e-mail address removed) (Pascal J. Bourguignon) wrote:
[snip]

We can implement iterators in lisp or scheme more easily than in C++,
thanks to closures.   Closures are a high level construct that allows
to implement in an abstract way a lot of concepts for which you would
use low level constructs such as  pointers or iterators in C++.
Perhaps that's the reason why a C++ programmer such as Alexander
Stepanov cannot see them in lisp, he's looking too low.

I suspect that it is not a matter of level of point of view. IMHO
Stephanov aims at abstracting algorithms while closures is a
functional/OOP artifact unifying algorithms behind a type.

AFAIK closures are unable to adapt with the semantic of the underlying
data while generic programs can.