|
Hello everyone,
How does one go about creating an array that can be passed to C++ methods (as a pointer to a DLL exported function) and an array that will not be garbage collected.
I need to create an array in c#, pass it to a C++ DLL and I want the C++ side of things to control the lifetime of the array (so to be able to call delete[] on it).
Is there any easy way to achieve this in C#?
Thanks,
Keith
|
|
|
|
|
That is not how it works. The party allocating is also responsible for freeing; having a managed object/array is fine, you can keep the GC from moving or collecting it, however it is also the managed side that should undo this.
I have an unfinished article about that and more here[^]. Have a look at the callback stuff, so your native part can report it is done with the array.
|
|
|
|
|
Thanks you. The GCHandle method seems to be exactly what I need.
Thanks,
Keith
|
|
|
|
|
you're welcome.
|
|
|
|
|
As Luc said, if creating the array in managed code, it must be freed in managed code too.
The normal way to protect stuff is to use GCHandle.Alloc[^] using GCHandleType.Pinned[^] followed when needed by GCHandle.Free[^]. However, Luc and I had a discussion about this a while ago and Luc conducted some tests which revealed some suprising results. Luc created another article with the test code here[^] which is worth study too.
DaveIf this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
|
|
|
|
|
Hi Dave,
After our chat I have updated the P/Invoke article so it now describes three rather than two ways of passing arrays; anyway, the OP needs the GCHandle approach, which has been included from day one.
Thanks for the support though.
|
|
|
|
|
Ah, I hadn't reread the P/Invoke one 
Good to have it all in one place 
DaveIf this helped, please vote & accept answer!
Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
|
|
|
|
|
DaveyM69 wrote: Ah, I hadn't reread the P/Invoke one
you should reread it regularly, it is work-in-progress after all. 
|
|
|
|
|
I've been looking around for an answer to this puzzling question, but so far no luck:
What's the compiler's try/finally equivalent of this code:
using (new SomeIDisposableClass())
{
SomeCode();
}
Thanks!
ShamWow
|
|
|
|
|
There's a CodeProject-article[^] that shows how it is translated
I are Troll 
|
|
|
|
|
Thanks for the quick response, but that article doesn't address my specific example where a variable is not explicitly declared inside the using statement.
ShamWow
|
|
|
|
|
Al Beback wrote: that article doesn't address my specific example where a variable is not explicitly declared inside the using statement.
Ah, my bad; it does almost the same the same thing, with the difference that you don't have a reference to your class. It still creates a class, disposing it in the finally.
public static void Main(string[] args)
{
using (new SomeIDisposableClass())
{
Console.WriteLine("Hello World!");
}
Console.ReadKey(true);
}
..translates to..
.method public hidebysig static
void Main(string[] args) cil managed
{
.entrypoint
.maxstack 2
.locals init (
[0] class using_test.SomeIDisposableClass CS$3$0000,
[1] bool CS$4$0001)
L_0000: nop
L_0001: newobj instance void
using_test.SomeIDisposableClass::.ctor()
L_0006: stloc.0
L_0007: nop
L_0008: ldstr "Hello World!"
L_000d: call void [mscorlib]System.Console::WriteLine(string)
L_0012: nop
L_0013: nop
L_0014: leave.s L_0026
L_0016: ldloc.0
L_0017: ldnull
L_0018: ceq
L_001a: stloc.1
L_001b: ldloc.1
L_001c: brtrue.s L_0025
L_001e: ldloc.0
L_001f: callvirt instance void
[mscorlib]System.IDisposable::Dispose()
L_0024: nop
L_0025: endfinally
L_0026: nop
L_0027: ldc.i4.1
L_0028: call valuetype
[mscorlib]System.ConsoleKeyInfo
[mscorlib]System.Console::ReadKey(bool)
L_002d: pop
L_002e: ret
.try L_0007 to L_0016 finally handler L_0016 to L_0026
}
I are Troll
|
|
|
|
|
IDisposable disposable = null;
try
{
disposable = new SomeIDisposableClass()
SomeCode();
}
finally
{
disposable.Dispose();
}
|
|
|
|
|
Sounds logical, although I would imagine the compiler would also add an extra check for whether "disposable" is null inside the finally block.
It's interesting that none of the examples you see out there for the using statement ever mention that if you don't assign your IDisposable type to an explicitly declared variable, the compiler will do it for you behind the scenes.
Thanks.
ShamWow
|
|
|
|
|
Why and when would you write a code like that?
As far as its equivalent is concerned, just see the IL through ILDAsm or reflector and it would make things a bit clear. 
modified on Monday, June 14, 2010 11:55 AM
|
|
|
|
|
d@nish wrote: Why and when would you write a code like that?
When you're interested in keeping track of when "SomeCode" begins and ends -- for logging, profiling, etc.
ShamWow
|
|
|
|
|
Use interceptor pattern for that. Check out Enterprise Library's Policy Injection Block to see how logging can be done before and after method call. (Search LogCallHandler)
|
|
|
|
|
d@nish wrote: Why and when would you write a code like that?
There's even a CodeProject-article[^] to answer that one! 
I are Troll 
|
|
|
|
|
Nice find.
From now on, I am going to have this in my windows forms application (of course with proper comments):
public class AppCursor : IDisposable
{
Cursor _currentCursor = null;
bool _setDefault;
public AppCursor(Cursor cursor, bool setDefault)
{
_currentCursor = Cursor.Current;
_setDefault = setDefault;
Cursor.Current = cursor;
}
#region IDisposable Members
public void Dispose()
{
Cursor.Current = (_setDefault) ? Cursors.Default : _currentCursor;
_currentCursor.Dispose();
_currentCursor = null;
}
#endregion
}
|
|
|
|
|
Chris should put that in the advertising. There is an app article for that.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
d@nish wrote: As far as its equivalent is concerned, just see the IL through ILDAsm or reflector and it would make things a bit clear.
I know, but shamefully, I'm IL challenged.
ShamWow
|
|
|
|
|
Wow, everyone got it wrong
Debug or Release?
The debug code (bugs in Reflector corrected by looking at the MSIL)
SomeIDisposableClass CS$3$0000;
bool CS$4$0001;
CS$3$0000 = new SomeIDisposableClass();
Label_0007:
try
{
SomeCode();
goto Label_0021;
}
finally
{
Label_0011:
CS$4$0001 = CS$3$0000 == null;
if (CS$4$0001)
{
goto Label_0020;
}
CS$3$0000.Dispose();
Label_0020:;
}
Label_0021:;
And yes, it is silly. It's storing the result of the null-check
The Release code
SomeIDisposableClass CS$3$0000;
CS$3$0000 = new SomeIDisposableClass();
Label_0006:
try
{
SomeCode();
goto Label_0017;
}
finally
{
Label_000D:
if (CS$3$0000 == null)
{
goto Label_0016;
}
CS$3$0000.Dispose();
Label_0016:;
}
Label_0017:
edit: the rules for goto-within-try are
If the goto statement exits one or more try blocks with associated finally blocks, control is initially transferred to the finally block of the innermost try statement. When and if control reaches the end point of a finally block, control is transferred to the finally block of the next enclosing try statement. This process is repeated until the finally blocks of all intervening try statements have been executed.
|
|
|
|
|
harold aptroot wrote: Wow, everyone got it wrong Debug or Release?The debug code (bugs in Reflector corrected by looking at the MSIL)
Bugs?
+5 
I are Troll
|
|
|
|
|
Bugs like this one.. if ((CS$3$0000 == null) != null)
That's not even possible, and the IL for that part is just
L_0011: ldloc.0
L_0012: ldnull
L_0013: ceq
L_0015: stloc.1
L_0016: ldloc.1
L_0017: brtrue.s L_0020
So Mr Reflector just skipped over a load/store and made up a comparison 
|
|
|
|
|
That's what I was looking for, thanks!
ShamWow
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
