1

Topic: int64: asynchronously to transfer C#-> a C ++-> C# through void*

Colleagues, greetings Faced the task: C# pulls request in a C ++/CLI a C ++/CLI pulls   at which it is possible to transfer void* as user data   causes the asynchronous code  the asynchronous code pulls callback which through With ++/CLI obeys in C# - there it is possible  this void * to understand, this concerns what request callback-notifikatsija Would be int - problems are not present, but here int64, and  all this disgrace in 32 bit and in any way differently (i.e. sizeof (void *) is equal 4, the upgrade on 64 bits is hardware is impossible). How is the in your opinion most elegant  than it through this chain managed-unmanaged-managed?

2

Re: int64: asynchronously to transfer C#-> a C ++-> C# through void*

Hello, Mr. Delphist, you wrote: MD> Would be int - problems are not present, but here int64. How is the in your opinion most elegant  than it through this chain managed-unmanaged-managed? Did not understand a little, what sort of a problem? Normally for this purpose use GCHandle. ToIntPtr (GCHandle. Alloc (@object)) Where @object - anything you like in ours AppDomain.

3

Re: int64: asynchronously to transfer C#-> a C ++-> C# through void*

Hello, samius, you wrote: S> S> GCHandle. ToIntPtr (GCHandle. Alloc (@object)) S> S> Where @object - anything you like in ours AppDomain. It would be desirable to avoid manual , because a chain asynchronous. In an ideal - all memory management remains in hands GC, the unmanaged-code receives a certain hendl/index/etc., which is then visible in C#-. I will repeat, at unmanaged API is only 32-bit "void *" for user-defined param in which and it is necessary  to ours int64 for once. And yes, forgot to mention: the unmanaged-code user-defined in parameter in any way does not use it, except as substitutes in parameter asynchronous C#-.

4

Re: int64: asynchronously to transfer C#-> a C ++-> C# through void*

Hello, Mr. Delphist, you wrote: MD> Hello, samius, you wrote: S>> S>> GCHandle. ToIntPtr (GCHandle. Alloc (@object)) S>> S>> Where @object - anything you like in ours AppDomain. MD> it would be desirable to avoid manual , because a chain asynchronous. I do not understand, than  can hinder an asynchronous chain. Generally, of course, GCHandle it is such dirty  for GC which to it should be bypassed all time and at considerable kol-ve GCHandle, there can be any problems. MD> in an ideal - all memory management remains in hands GC, the unmanaged-code receives a certain hendl/index/etc., which is then visible in C#-. I will repeat, at unmanaged API is only 32-bit "void *" for user-defined param in which and it is necessary  to ours int64 for once. So it is any associative container with  int plus the organization of storage of the free indexes. I for UserContext use the list of arrays of the fixed length which grows necessarily and writes down empty seats in a chain. In trivial execution - combination Dictionary <int, T> and Stack <int>.

5

Re: int64: asynchronously to transfer C#-> a C ++-> C# through void*

Hello, samius, you wrote: S> So it is any associative container with  int plus the organization of storage of the free indexes. S> I for UserContext use the list of arrays of the fixed length which grows necessarily and writes down empty seats in a chain. S> in trivial execution - combination Dictionary <int, T> and Stack <int>. Here I just on similar  while stopped, something is simple suddenly there is more elegant.