COM : Interface from c# to c++ problem with IntPtr type

[Thomas T. Veldhouse]

Check this:
http://msdn2.microsoft.com/en-us/library/s3f49ktz.aspx

Indeed ... and this suprises me greatly. I hold little respect for the
implementation then as there is absolutely no difference between int and long,
which with the advent of 64-bit architectures, should be obvious. It IS
implemented "correctly" on Linux, FreeBSD, Solaris ... yada yada yada.

 

[Thomas T. Veldhouse]

It does say it, right next to where it says that a HANDLE is still 32-bits.
Look for the red "Editors' Note" noting that the previous sentence is wrong.

Yeah, it says the HANDLE is a pointer type and is actually 64-bit (what it
indicates is wrong was the previous sentence saying it was still 32-bit).

 

[Eric]

Change your INT_PTR into a void*, IntPtr is marshaled as void* type by the
interop marshaler.

OK, I find the problem. IntPtr have no built-in type in C++ data type.

http://msdn2.microsoft.com/en-us/library/hfa3fa08.aspx

So, I have two solutions for manipulate pointer values.

1- Always use 64-bit data type (like Int64)
2- Create two version of the code (one for 32-bit and one for 64-bit)

Which solution will be the best (performance and practical way) ?

Eric

 

[Willy Denoyette [MVP]]

OK, I find the problem. IntPtr have no built-in type in C++ data type.

http://msdn2.microsoft.com/en-us/library/hfa3fa08.aspx

So, I have two solutions for manipulate pointer values.

1- Always use 64-bit data type (like Int64)
2- Create two version of the code (one for 32-bit and one for 64-bit)

Which solution will be the best (performance and practical way) ?

Eric

Not sure why you consider Int64 as valid, what you are passing is a HWND
which is a void pointer, that is, a 64 bit integer value on 64 bit windows
and 32 bit on 32 bit windows, so you can't use this type for both.
Regasm (the tool used to build the tlb), produces long* for an IntPTR wheh
run on 32 bit, it produces a Int64* when run on 64 bit, which is
semantically correct (a void is not oleautomation compliant).

However, when you want platform independence, you need to declare your
pointer as void* (in IDLE), you can't use regasm in this case, you need to
declare your C# interface definition by hand coding.

Willy.

 

[Carl Daniel [VC++ MVP]]

Indeed ... and this suprises me greatly. I hold little respect for the
implementation then as there is absolutely no difference between int and
long,
which with the advent of 64-bit architectures, should be obvious. It IS
implemented "correctly" on Linux, FreeBSD, Solaris ... yada yada yada.

The difference here is that the decision to leave long at 32 bits for 64 bit
Windows was based on analysis of 100's of millions of lines of existing code
which showed that leaving long at 32 bits would break less code than
changing it to 64 bits, while the *nix compilers just did what they thought
was "right" and backward compatibility be damned. Both decisions are valid,
but have different ramifications. Both are completely valid and consistent
with the C and C++ standards. The C99 decision to add sized integral types
to the language is really the best answer.

-cd

 

[Willy Denoyette [MVP]]

Indeed ... and this suprises me greatly. I hold little respect for the
implementation then as there is absolutely no difference between int and
long,
which with the advent of 64-bit architectures, should be obvious. It IS
implemented "correctly" on Linux, FreeBSD, Solaris ... yada yada yada.

The size of integral types is "compiler" implementation dependent, the
Windows team decided (long ago) to maintain the sizes of these types as is.
Please refer to this for more info:
http://msdn.microsoft.com/library/d...ry/en-us/win64/win64/abstract_data_models.asp

Willy.

 

[Thomas T. Veldhouse]

The difference here is that the decision to leave long at 32 bits for 64 bit
Windows was based on analysis of 100's of millions of lines of existing code
which showed that leaving long at 32 bits would break less code than
changing it to 64 bits, while the *nix compilers just did what they thought
was "right" and backward compatibility be damned. Both decisions are valid,
but have different ramifications. Both are completely valid and consistent
with the C and C++ standards. The C99 decision to add sized integral types
to the language is really the best answer.

There is no real issue of backward compatibility with precompiled binaries, as
they are linked against 32-bit version of the C library. If you port to a new
platform (i.e. Win64), then a responsible plan will be to test just such a
thing. My opinion, as stated, is that long should be 64-bit. May as well
just remove it for all it is worth now. I seem to recall a time when
Microsoft resisted the move to ANSI C++, mainly because of all the compiler
hacks in place to get MFC to work [and later ATL]. Backward compatibility
with source code seems rather evasive to me as in then end, Microsoft has
always complied with the majority [in this case, just about every other 64-bit
platform defines "long" as 64-bits]. Heck, in C, preprocessor macros are the
name of the game to stay compatible between versions of windows ...

 

[Thomas T. Veldhouse]

The size of integral types is "compiler" implementation dependent, the
Windows team decided (long ago) to maintain the sizes of these types as is.
Please refer to this for more info:
http://msdn.microsoft.com/library/d...ry/en-us/win64/win64/abstract_data_models.asp

I agree with you that it "conforms". I don't agree that it is "correct". I
think the correct thing to do was to make long 64-bits [like just about the
rest of the 64-bit world].