Archived

This topic is now archived and is closed to further replies.

Zyme

dotnet (c#) IntPtr

Recommended Posts

Zyme    122
Has any one actualy found a simple quick way of forcing an array of classes/structs into an IntPtr value type ?

Share this post


Link to post
Share on other sites
VizOne    598
You won't be able to get an IntPtr to an array of class-instances as these are garbage collected and their address may change. However, with an array of struct-instances it is possible. However, only use it for interop with existing native code. Try to find a more ".NET-way" of doing it in all (well, most...) other cases...


[StructLayout(LayoutKind.Sequential, Pack = 4)]
struct Data
{
public int bla;
public int foo;
}

class Apl
{
public static void Main()
{
Data[] data = new Data[4];

unsafe
{
fixed(Data * ptrData = &data[0])
{
IntPtr ptr = new IntPtr(ptrData);

// do interop here...
}
}
}
}


Regards,
Andre Loker


[edited by - VizOne on May 25, 2004 5:27:42 PM]

Share this post


Link to post
Share on other sites
VizOne    598
quote:
Original post by Zyme
damn it, i didnt want to use unsafe memory alocations :/ oh well i guess i have too


The code does not allocate memory. It simply allows to use features that are not as controlled as the sandbox the code normally runs in. However, "unsafe" code can be perfectly safe if written correctly.

The "fixed" simply pins the array within memory and prevents it from being moved during garbage collections.

Regards,
Andre

Share this post


Link to post
Share on other sites
VizOne    598
quote:
Original post by Arild Fines
Why is everyone so worried about using unsafe? It''s certainly no less safe than using raw pointers in C++.


You are right, it isn''t less safe. However, one aim of .NET is to make programs *safer* than their native brothers. And I''d not suggest "falling back" to less safety without a good reason (e.g. interop). Most tasks in C# can be done without "unsafe" blocks. It''s nice to have ''em, but don''t use them if you don''t have to.

Regards,
Andre

Share this post


Link to post
Share on other sites
Zipster    2365
There are other reasons why you should avoid unsafe unless you have to use it. Security policies can only be applied to verifiably type-safe assemblies. Unfortunately, in order to use unsafe you must skip the JIT verification process. Only a fully-trusted assembly can execute if it isn't verifiably type-safe. While this might not be an issue for many, since code that originates from the local machine is automatically fully-trusted, who knows what kind of environment you'll be working in later on. The administrator could have user-based security policies in effect that don't fully trust your code. Or, if you're running an assembly from an internet zone you can bet that there's practically no trust at all.

Then again, managed C++ code by default isn't verifiably type-safe, meaning that it always needs to be fully-trusted. So maybe in practice, you won't be seeing too many anal administrators in regards to strict code access security, especially if you're writing managed C++ code.

Just another reason why you shouldn't undermine .NET security if you don't have to

[edited by - Zipster on May 25, 2004 8:00:54 PM]

Share this post


Link to post
Share on other sites
Zyme    122
quote:
Original post by VizOne
quote:
Original post by Zyme
damn it, i didnt want to use unsafe memory alocations :/ oh well i guess i have too


The code does not allocate memory. It simply allows to use features that are not as controlled as the sandbox the code normally runs in. However, "unsafe" code can be perfectly safe if written correctly.

The "fixed" simply pins the array within memory and prevents it from being moved during garbage collections.

Regards,
Andre


yes i am aware of what it does, i am just slightly annoyed that i have no choice but to deal with the management of it my self.

Share this post


Link to post
Share on other sites