Re: Microsoft Document Explorer - VC++ 2005

Tech-Archive recommends: Fix windows errors by optimizing your registry



Hmmm. Let me see:

> I think this is because it is Beta and the documentation is redesigned. Current
> Help in 2003 is OK.

Where does this leave me with VC++ 2005 - do you acknowledge this is a
problem which is going to be fixed, i.e. Microsoft knows about it?

Well Ioannis, you may be correct but I am going by the documentation I read:

Start Quote:
Declares a handle to an object on the managed heap.
A handle to an object on the managed heap points to the "whole" object, and
not to a member of the object.

See gcnew for information on how to create an object on the managed heap.

In Visual C++ 2002 and Visual C++ 2003, __gc * was used to declare an object
on the managed heap. The ^ replaces __gc * in the new syntax.

Remarks
The common language runtime maintains a separate heap on which it implements
a precise, asynchronous, compacting garbage collection scheme. To work
correctly, it must track all storage locations that can point into this heap
at runtime. ^ provides a handle through which the garbage collector can track
a reference to an object on the managed heap, thereby being able to update it
whenever that object is moved. Member selection through a handle (^) uses the
pointer-to-member operator (->).
End Quote.

Seems to me that when one uses ^, the compiler generates code so that it is
used as an index into an array of pointers to objects on the *managed heap*
the CLR uses to manage the separate heap.
So in this sense it is not a pointer and can not be used as one. So although
you state that *Handles have different semantics than usual pointers* - this
is only true for the CLR for in all previous versions of C++, it was
essentially the same as a pointer. Strange then that it is called a *handle*
and not a *gc-index*.

> In .NET, C++ is two worlds. The unmanaged world and the managed world. In
> the managed world every .NET feature is provided separately from the
> unmanaged world features.

So I am led to believe. Your webpage makes sense. Can I take it for granted
everything you state is correct or do I need to make yet more comparisons
against other sources? :-)
.



Relevant Pages

  • Re: Microsoft Document Explorer - VC++ 2005
    ... What I know so far, is that they are redesigning MSDN documentation for 2005 from scratch, so I suppose any documentation problems will be fixed. ... So although you state that *Handles have different semantics than usual pointers* - this is only true for the CLR for in all previous versions of C++, it was essentially the same as a pointer. ... In both cases, handles/managed pointers have been different than native pointers, in the sense that their values change whenever the object is moved in the managed heap by the CLR. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: managed string -> unmanaged string
    ... > And that's what the garbage collector does isn't it. ... Only managed handles in places that are under the GC control (i.e the ... managed heap, or the managed stack). ... That's the reason to have pinning pointers: ensuring the gc doesn't move the ...
    (microsoft.public.dotnet.framework)
  • Re: managed string -> unmanaged string
    ... > And that's what the garbage collector does isn't it. ... Only managed handles in places that are under the GC control (i.e the ... managed heap, or the managed stack). ... That's the reason to have pinning pointers: ensuring the gc doesn't move the ...
    (microsoft.public.vc.language)
  • Re: managed string -> unmanaged string
    ... > And that's what the garbage collector does isn't it. ... Only managed handles in places that are under the GC control (i.e the ... managed heap, or the managed stack). ... That's the reason to have pinning pointers: ensuring the gc doesn't move the ...
    (microsoft.public.dotnet.languages.vc)
  • Re: what does ^ mean
    ... that notation mean? ... In C++/CLI it's a handle to an object on the managed heap. ... find the documentation in MSDN. ...
    (microsoft.public.dotnet.languages.vc)