none
IntPtr RRS feed

Answers

All replies

  • Thanks Rudedog,

     

     

    Is my understanding in item (1) of my original post correct?

     

     

     

    regards,

    George

    Saturday, April 19, 2008 1:45 PM
  • I would say that you are pretty much on target. 

    Look up the Marshal class and MarshalByRefObject in your Object Browser or in the MSDN library.

     

    Rudedog

     

    Saturday, April 19, 2008 1:50 PM
  • I am confused, Rudedog.

     

     

    I am asking for class FileStream, why do you want me to look up class Marshal and MarshalByRefObject?

     

     Rudedog2 wrote:

    I would say that you are pretty much on target. 

    Look up the Marshal class and MarshalByRefObject in your Object Browser or in the MSDN library.

     

    Rudedog

     

     

     

    regards,

    George

    Saturday, April 19, 2008 1:53 PM
  • I had thought you were asking about IntPtr not any of the Stream classes.  You asked when and why would one use IntPtr.

    Saturday, April 19, 2008 2:42 PM
  • IntPtr is simply a wrapper for a void* - I suggest you use Reflector to look at how simple its implementation is:

    Code Snippet

    [Serializable, StructLayout(LayoutKind.Sequential), ComVisible(true)]
        public struct IntPtr : ISerializable
        {
            private unsafe void* m_value;
            public static readonly IntPtr Zero;


            [ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
            internal unsafe bool IsNull()
            {
                return (this.m_value == null);
            }

            [ReliabilityContract(Consistency.MayCorruptInstance, Cer.MayFail)]
            public unsafe IntPtr(int value)
            {
                this.m_value = (void*) value;
            }


    etc etc...



    FileStream uses IntPtr in several of its constructors and exposes its handle as an IntPtr. Internally the FileStream wraps the Inptr in a SafeFileHandle.

    Reflector can often be the best way of truely understanding how many NET classes work.


    Saturday, April 19, 2008 3:38 PM
  • > We have easy to use class like StreamWriter, when and why do we need to use IntPtr?

     

    You almost certainly won't need to touch the IntPtr type unless you are calling native API functions because you want to use functionality that is not directly supported by the .NET Framework classes.

     

    This ability to invoke native API functions is called "platform invoke" or P/Invoke for short.  IntPtr is used to store native memory addresses and handles.

     

    Saturday, April 19, 2008 9:22 PM
  •  Alex Cater wrote:

    Code Snippet

    [Serializable, StructLayout(LayoutKind.Sequential), ComVisible(true)]
        public struct IntPtr : ISerializable
        {
            private unsafe void* m_value;
           


     

    What are potential negative consequences of enabling /unsafe for the compiler?

     

    Thanks.

    Saturday, April 19, 2008 11:41 PM
  • AlexBB,

     

    Basically, it bypasses the CLR, Common Language Runtime.  The CLR manages garbage collection.  The converse is now the developer must manage memory, instead of producing application code.  As for memory reference pointers, the basic difference is that with unmanaged code those pointers are fixed and reference a specific memory location.  In managed code those pointers are relative, and point to a moveable location managed by the CLR.

     

    Rudedog

     

    Sunday, April 20, 2008 1:10 AM
  • Cool, Alex!

     

     

     Alex Cater wrote:
    IntPtr is simply a wrapper for a void* - I suggest you use Reflector to look at how simple its implementation is:

    Code Snippet

    [Serializable, StructLayout(LayoutKind.Sequential), ComVisible(true)]
        public struct IntPtr : ISerializable
        {
            private unsafe void* m_value;
            public static readonly IntPtr Zero;


            [ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]
            internal unsafe bool IsNull()
            {
                return (this.m_value == null);
            }

            [ReliabilityContract(Consistency.MayCorruptInstance, Cer.MayFail)]
            public unsafe IntPtr(int value)
            {
                this.m_value = (void*) value;
            }


    etc etc...



    FileStream uses IntPtr in several of its constructors and exposes its handle as an IntPtr. Internally the FileStream wraps the Inptr in a SafeFileHandle.

    Reflector can often be the best way of truely understanding how many NET classes work.


     

     

    regards,

    George

    Sunday, April 20, 2008 8:14 AM
  • I ask both, Rudedog. :-)

     

     

    Thanks for your help and my English is not very good.

     

     Rudedog2 wrote:

    I had thought you were asking about IntPtr not any of the Stream classes.  You asked when and why would one use IntPtr.

     

     

    regards,

    George

    Sunday, April 20, 2008 8:15 AM
  • Thanks BinaryCoder,

     

     

    Your description is clear.

     

     BinaryCoder wrote:

    > We have easy to use class like StreamWriter, when and why do we need to use IntPtr?

     

    You almost certainly won't need to touch the IntPtr type unless you are calling native API functions because you want to use functionality that is not directly supported by the .NET Framework classes.

     

    This ability to invoke native API functions is called "platform invoke" or P/Invoke for short.  IntPtr is used to store native memory addresses and handles.

     

     

     

    regards,

    George

    Sunday, April 20, 2008 8:16 AM
  • Hi Rudedog,

     

     

    1.

     

    You mean for unsafe types, CLR will not manage the memory, and it is developer's responsible to free the memory?

     

    2.

     

    Can I understand unsafe types are not in managed heap, but unmanaged memory? :-)

     

     Rudedog2 wrote:

    AlexBB,

     

    Basically, it bypasses the CLR, Common Language Runtime.  The CLR manages garbage collection.  The converse is now the developer must manage memory, instead of producing application code.  As for memory reference pointers, the basic difference is that with unmanaged code those pointers are fixed and reference a specific memory location.  In managed code those pointers are relative, and point to a moveable location managed by the CLR.

     

    Rudedog

     

     

     

    regards,

    George

    Sunday, April 20, 2008 8:17 AM
  •  AlexBB wrote:

     

    What are potential negative consequences of enabling /unsafe for the compiler?

     

    Thanks.

     

    Unsafe code introduces security and stability risks. It is typically referred to as unverifiable code, which is code whose safety cannot be verified by the CLR. As a result, the CLR will only execute unsafe code if it is in a fully trusted assembly. See Code Access Security (CAS)

     

    Sunday, April 20, 2008 10:12 AM
  • If not truly trusted assembly, Alex, CRL will refuse to execute the unsafe code? :-)

     

     Alex Cater wrote:

     AlexBB wrote:

     

    What are potential negative consequences of enabling /unsafe for the compiler?

     

    Thanks.

     

    Unsafe code introduces security and stability risks. It is typically referred to as unverifiable code, which is code whose safety cannot be verified by the CLR. As a result, the CLR will only execute unsafe code if it is in a fully trusted assembly. See Code Access Security (CAS)

     

     

     

    regards,

    George

    Sunday, April 20, 2008 10:15 AM
  •  George2 wrote:

    Hi Rudedog,

     

    1. You mean for unsafe types, CLR will not manage the memory, and it is developer's responsible to free the memory?

     

    2. Can I understand unsafe types are not in managed heap, but unmanaged memory? :-)

     

    regards,

    George

     

    No. The CLR still manages types with unsafe code. The only difference is that the code becomes unverifiable. The unsafe keyword simply allows you to declare a context in which you can use pointers; quite often for calling native functions that require pointers or in an attempt to increase an applications performance by using pointer arithmetic and/or removing array bounds checks.

     

    "If you use unsafe code, it is your responsibility to ensure that your code does not introduce security risks or pointer errors" (MSDN).

    Sunday, April 20, 2008 10:41 AM
  • George,

     

    Yes exactly. If you are running the assembly locally it runs under full trust (usually) but if you were executing via download over HTTP or from a network share, for example, then it would fail. You would have to specifically configure your machine to trust the specific assembly or adjust .NET security.

    Sunday, April 20, 2008 10:51 AM
  • Thanks Alex,

     

     

    I found I need to pick-up some knowledge of unsafe code and .Net security configuration. Do you have any referred articles?

     

     Alex Cater wrote:

    George,

     

    Yes exactly. If you are running the assembly locally it runs under full trust (usually) but if you were executing via download over HTTP or from a network share, for example, then it would fail. You would have to specifically configure your machine to trust the specific assembly or adjust .NET security.

     

     

    regards,

    George

    Sunday, April 20, 2008 11:37 AM