Re: Garbage Collection - Stop Making Trash

From: Ioannis Vranos (ivr_at_guesswh.at.grad.com)
Date: 08/11/04 

Date: 11 Aug 2004 16:21:48 -0400

Nicola Musatti wrote:

> You are forgetting the fast track process. It appears very likely that
> as soon as the ECMA standard is ratified, it will be submitted to ISO.
> Due to the fast track thing, it is also likely that C++/CLI will
> become an ISO standard *before* the next ISO C++ standardization round
> is over.
>
> Is it likely that, at that point, the C++ committee will not take
> C++/CLI into account? The net result is that decision that should have
> pertained to the C++ committee will have been taken by others.

Ok, they may take C++/CLI into account. And what is wrong with that?
There are many other standards they also take into account.

> > Yes however C++/CLI has low level access to CLI that couldn't be
> > possible through a library.
>
> Can you provide an example? Personally I don't think I have
> encountered such a thing.

I do not know much C++/CLI, have just started checking it in my free
time, but in "managed extensions" for example you can create a pin
pointer to make a managed object to not be moved by the garbage
collector in the heap and pass it to regular ISO C++ functions which
take pointers. An example:

#using <mscorlib.dll>

template<class T>

inline void somefun(T *p)
{
  p->x++;
}

__gc struct whatever
{
  int x;

  whatever():x(1) {}
};

int main()
{
  whatever *p=__gc new whatever;

  whatever __pin *r=p;

  somefun(r);
}

In the above, as long as the whatever object is pointed by the pin
pointer, it cannot be moved by the GC and will not be garbage collected.
And this pointer can be used in regular ISO C++ functions.

Another example is:

#using <mscorlib.dll>

__value struct whatever
{
  int x;

  whatever():x(1) {}
};

int main()
{
  whatever wobj;

  __box whatever *p=__box(wobj);

}

Deterministic finalisation:

#using <mscorlib.dll>

__gc class whatever
{
  public:
  ~whatever() { }

};

int main()
{
  whatever *p= __gc new whatever;

  delete p;
}

And these in "managed extensions". C++/CLI is far better than managed
extensions. It provides more simple and clean syntax, separate things
are kept separate: for example handles and pointers are different
things, it provides new stuff, mscorlib.dll is not needed for C++/CLI
code, more powerful control, deterministic destruction with managed
objects in the *stack*, no need for Dispose definition etc. These things
are not possible currently with other languages like C#, and some will
probably never will like C++/CLI pin_ptr.

ISO C++ and C++/CLI can interoperate more elegantly, cleanly and
efficiently.

Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]

Relevant Pages

  • Re: Memory Structure Pointer Problems
    ... typedef struct sta { ... char* name; ... int num_cmpnds; ... A pointer to a struct cmp is almost ...
    (comp.lang.c)
  • Re: C# - getting binary data from .lib
    ... Use Marshal.AllocHGlobal to allocate the memory and pass this IntPtr to the ... int retCode = create(id, scale, ptrImage); ... You now control the pointer returned. ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Another spinoza challenge
    ... You should test against the int type's limits: ... typedef struct complex ... a pointer to an integer ... A macro is preferable because it is replaced by inline code, ...
    (comp.lang.c)
  • Re: C# - getting binary data from .lib
    ... int create(int id, int scale, unsigned char *image); ... unsigned char* ptrImage = NULL; ... // Read through entire pointer byte by byte and put into managed array ...
    (microsoft.public.dotnet.framework.interop)
  • Re: C# - getting binary data from .lib
    ... then there is a problem with the ptrImage ... int retCode = create(id, scale, ptrImage); ... You now control the pointer returned. ...
    (microsoft.public.dotnet.framework.interop)