Actually the C++ example just happens to be using the syntax that is also used for pointers. This doesn't make it a pointer.
In this declaration: > Foo * f = new Foo(); because Foo is a managed type, then that's implicitly a __gc * type. That means that it's a reference to a managed object. They happen to use the * and the -> syntaxes. Stan Lippman has had a fair amount to say about why this was a really unhelpful thing to do. Here: http://blogs.msdn.com/slippman/archive/2003/12/02/58439.aspx he said "We want to call the type a handle rather than a pointer or reference because both of these terms carry baggage from the native side." He's referring to .NET managed references there, and why they're going to stop calling them pointers going forwards. In this article, http://blogs.msdn.com/slippman/archive/2003/12/01/58438.aspx he says: "in the original design ... the language designers felt that the only viable representation of the .NET reference type, was to reuse the existing pointer syntax" but then goes on to list all the reasons why these things are nothing like traditional C++ pointers. And then specifically on why it was actually a bad idea to use pointer syntax here: "At first blush, the pointer solution seemed reasonable. After all, it seems the natural target of a new expression, and both support shallow copy. One problem is that a pointer is not a type abstraction, but a machine representation (with a tag type recommendation as to how to interpret the extent and internal organization of the memory following the address of the first byte), and this falls short of the abstraction the software runtime imposes on memory and the automation and security one can extrapolate from that. This is a historical problem between object models that represent different paradigms. "A second problem is the [metaphor alert -- a strained metaphor is about to be attempted -- all weak-stomached readers are advised to hold on or jump to the next paragraph] necessary entropy of a closed language design which is constrained to reuse constructs that are both too similar and significantly different and result in a dissipation of the programmer's energy in the heat of a desert mirage. [metaphor alert end]. "Reusing the pointer syntax turned out to be a source of cognitive noise for the programmer: you have to make too many distinctions between the native and managed pointers, and this interferes with the flow of coding, which is best managed at a higher level of abstraction. That is, there are times when we need to, as system programmers, go down a notch to squeeze some necessary performance, but we don't want to dwell at that level. " And there's more - dig around Stan Lippman's blog on this topic, and two themes will keep coming back at you. (1) in V1.0 and v1.1, Managed C++ is just reusing the pointer syntax for an entirely different kind of thing. Manager 'pointers' are not really pointers in any traditional C++ sense, they just happen to share a syntax. Their semantics are considerably different. (2) using the same syntax and a similar name really confused people and was, with hindsight, not a helpful decision. You're providing a great example of (1) - you are insisting that these things are pointers. And it's easy to fall into this trap - they use pointer syntax and are, confusingly, referred to as 'managed pointers'. But this is just how managed C++ (v1) chooses to present managed references. These things have completely different behaviour to normal C++ pointers. It's C++ that is the odd one out here, by reusing its old pointer syntax for the new concept of a managed reference. Also, you say this: > certain things cannot or should not be done > the managed pointers, thats why the c++-team > will introduce the handle type, so we cant do > these certain things anymore. Actually most of the things can't be done with managed pointers either because...they're not pointers! The change to the handle syntax is mostly just that - a change of syntax. The reason the C++ team is introducing a new syntax is not to stop you doing things you shouldn't with managed references. -- Ian Griffiths - DevelopMentor (RSS: http://www.interact-sw.co.uk/iangblog/rss2.0 ) > -----Original Message----- > From: Heath Ryan > > Hi Ian, > > Thanks for your lengthy explaination ;) > > I am aware that in c++ > managed pointers are different from > non-managed pointers; certain things cannot or should not > be done the managed pointers, thats why the c++-team will introduce the > handle type, so we cant do these certain things anymore. > > But IMHO this doesnt removed the fact they are pointer(-a-like)s... > > See folling snippets: > > <C#> > void func() > { > Foo f = new Foo(); > f.Bar(); > f = null; > f = new Foo(); > f.Bark(); > f = null; > } > </C#> > > if I want to translate this to VB(6) we get this > > <VB> > Procedure func > Dim f As Foo > set f = new Foo > f.Bar > set f = nothing > set f = new Foo > f.Bark > set f = nothing > End Procedure > </VB> > > if I want to translate to C++(unmanaged) we get this > > <C++> > void func() > { > Foo * f = new Foo(); > f->Bar(); > delete f; > f = new Foo(); > f->Bark(); > delete f; > > } > </C++> > > In c++ I cannot translate it into reference types like > > <C++> > void func() > { > Foo & f = Foo(); <- object lives on the stack rather than the heap > f.Bar(); > f = 0; // <- not possible with c++ reference > f = Foo(); // <- reassignment not possible with c++ reference > f.Bark(); > f = 0; // <- not possible with c++ reference > } > </C++> > > Now, since the best translation from C#/VB into C++ is with pointers, > why do the other langauages call them references? > > Apart from the . notation and the * notation, they behave like c++ > pointers, > in both the C# and VB languages... > > sidenote: > In the past, I have worked on a project that was passing objects between > C++ > and Delphi. In C++, these objects were pointers, in Delphi they felt like, > lets says, 'references', while underneath the language, they were > pointers. > Also when passing objects between VB(6) and C++, we encountered the same > thing. In VB they felt like 'references', but underneath they were > pointers. > > Having said this, I recall the NullREFERENCEException... > but i cannot see why they call them references rather pointers. =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
