Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > pointers

Reply
Thread Tools

pointers

 
 
mikethebike
Guest
Posts: n/a
 
      09-21-2009
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

 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      09-21-2009
mikethebike wrote:
> 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.

--
Ian Collins
 
Reply With Quote
 
 
 
 
Pascal J. Bourguignon
Guest
Posts: n/a
 
      09-21-2009
Ian Collins <(E-Mail Removed)> writes:

> mikethebike wrote:
>> 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.


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.
--
__Pascal Bourguignon__
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      09-21-2009
Pascal J. Bourguignon wrote:
> Ian Collins <(E-Mail Removed)> writes:
>
>> mikethebike wrote:
>>> 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.

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

--
Ian Collins
 
Reply With Quote
 
Pascal J. Bourguignon
Guest
Posts: n/a
 
      09-21-2009
Ian Collins <(E-Mail Removed)> writes:

> Pascal J. Bourguignon wrote:
>> Ian Collins <(E-Mail Removed)> writes:
>>
>>> mikethebike wrote:
>>>> 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.

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


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.

--
__Pascal Bourguignon__
 
Reply With Quote
 
Keith H Duggar
Guest
Posts: n/a
 
      09-21-2009
On Sep 21, 7:27 am, (E-Mail Removed) (Pascal J. Bourguignon) wrote:
> Ian Collins <(E-Mail Removed)> writes:
> > Pascal J. Bourguignon wrote:
> >> Ian Collins <(E-Mail Removed)> writes:

>
> >>> mikethebike wrote:
> >>>> 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.

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

>
> 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
 
Reply With Quote
 
Pascal J. Bourguignon
Guest
Posts: n/a
 
      09-21-2009
Keith H Duggar <(E-Mail Removed)> writes:

> On Sep 21, 7:27 am, (E-Mail Removed) (Pascal J. Bourguignon) wrote:
>> Ian Collins <(E-Mail Removed)> writes:
>> > Pascal J. Bourguignon wrote:
>> >> Ian Collins <(E-Mail Removed)> writes:

>>
>> >>> mikethebike wrote:
>> >>>> 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.

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

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


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.


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


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 Bourguignon__
 
Reply With Quote
 
Pascal J. Bourguignon
Guest
Posts: n/a
 
      09-21-2009
http://www.velocityreviews.com/forums/(E-Mail Removed) (Pascal J. Bourguignon) writes:
> 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?

--
__Pascal Bourguignon__
 
Reply With Quote
 
Richard Herring
Guest
Posts: n/a
 
      09-21-2009
In message
<(E-Mail Removed)>,
mikethebike <(E-Mail Removed)> writes
>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.

--
Richard Herring
 
Reply With Quote
 
joseph cook
Guest
Posts: n/a
 
      09-21-2009
On Sep 21, 9:24*am, (E-Mail Removed) (Pascal J. Bourguignon) wrote:

> 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
 
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
pointers, pointers, pointers... cerr C Programming 12 04-07-2011 11:17 PM
Does deleting a container of pointers also delete the (contained) pointers? Xamalek C++ 7 11-04-2003 04:17 PM
c++: pointers to pointers A C++ 3 10-29-2003 01:15 PM
pointers to pointers // exception handling error muser C++ 3 09-18-2003 06:19 PM
Template specialization of pointers with function pointers Phil C++ 1 09-16-2003 02:17 AM



Advertisments