I'm having a problem with C++/CLI and J#.
I am writing a class library in C++/CLI and want to use it from J#.
I narrowed down my code and wrote a repro:
a.cpp:
#using <mscorlib.dll>
#include <stdio.h>
using namespace System;
namespace AA
{
public ref class A
{
public:
unsigned long Print()
{
printf("Hello\n");
return 0;
}
};
}
b.jsl:
import System.*;
import AA.*;
public class Test
{
public static void main(String[] args)
{
A a = new A();
a.Print();
}
}
To compile do:
cl /clr /O2 /MD /c a.cpp
link /dll /out:a.dll a.obj
mt -outputresource:a.dll;#2 -manifest a.dll.manifest
vjc /out:b.exe b.jsl /reference:a.dll
At runtime I get:
Unhandled Exception: System.MissingMethodException: Method not found: 'UInt32 AA.A.Print()'.
The problem is that I'm using "unsigned long" as return value. If I would use System::UInt32 as suggested it would work fine.
The same C++/CLI code works fine from C# and VB.NET though. This makes me think that J# has a bug.
Doesn't "unsigned long" get mapped to UInt32
From the MSIL Decompiler tool I see that the protype of the function is like follows:
.method public hidebysig instance uint32 modopt([mscorlib]System.Runtime.CompilerServices.IsLong)
Print() cil managed
Does this mean that the .NET framwork has two types UInt32 and uint32 which are not equal
Thanks in advance.
-- Henrik
Problem with C++/CLI and J# interaction bug
electrickghost
We will surely like to assist you. I would request you to contact developers support at (800) 936-5800. They will put you across to the appropriate owner in our team or me.
We investigated more in this issue and here is what our Program Manager 'Pratap Lakshman" has to say...
"Forget about the sign for a moment. In C++/CLI,
long and int are distinct types that can be used in different overloaded functions. Since they are also the same size (4 bytes) on Win32. The C++ compiler needs some way to distinguish between Int32 as an int and Int32 as a long. Hence it emits the modopt (if you change the return type to int, you’ll see the modopt go away). The modopt does end up being part of the signature, so the call instructions need to include the modopt in the signature. The missing method exception is because the call instruction does not include the modopt, and thus is naming a different function. Notice that the C# compiler emits the modopt in the signature.Such use of
modopt is indeed CLS Compliant too. Refer the doc "ECMA-335: CLI Partition I - Architecture" at http://msdn.microsoft.com/netframework/ecma/:CLS Rule 35: The
CLS does not allow publicly visible required modifiers (modreq, see Partition II),but does allow optional modifiers (modopt, see Partition II) it does not understand. (§9.7)However consumers of this may run into problems if two overloads use the same type but different modopts. C++/CLI itself, ignores such functions in that scenario, treating them as if they never existed. This is one of those areas of the CLS where is it possible that there could be other language compilers on .NET that have similar problems as the J# compiler does when consuming such functions. So, you should be very careful about authoring such functions if you intend them to be consumed cross-language.
As a general guidance whenever you want to write code meant to be consumed cross-language, write CLS Compliant code. The good news is that the J# compiler can do automatic CLS Compliance checking."So in summary this is surely a bug on us.
Thanks for reporting this.
Morten Meldal
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx feedbackid=84f1a562-bb81-486b-ab6f-eb0a7777c82c
-- Henrik
Tsutomu YASUI
This is not a bug with the compiler actually. J# compiler doesn't support unsigned int as primitive data type because java also doesn't have them. We comply with java specs here. If user wants to use unsigned int then (s)he has to use System.UInt32 explicitly.
Anyways, you are welcome to file the bug on us. We will definitely like to fix it if it is possible and doesn't violate any standard java behavior.
Thanks.
JBailo
I cannot agree with what you're saying. The compiler must either write working CLI code or give a warning or error message. If it gives no feedback it's assumed that the outputted code will work. Delaying the problem until runtime means something went wrong at compilation stage.
-- Henrik
Jayasurya
Thanks in advance.
-- Henrik
Jason Shave
However it must be a bug. I see some ways of fixing it:
1. Change "unsigned long" to become UInt32.
2. Change J# to produce working code.
3. Report an error when compiling the code.
-- Henrik
Alex J.
Hi Henrik,
I am not very sure if I can use my email ID on public forums. It could be a violation of our forum guidelines. I would rather request to use the contact details I have given to you. Depending on your problem scope they will direct you to right person in our team.
Thanks.
annh
Thanks you.
Best regards,
Henrik
Manjax
Accroding to msdn, in C++/CLR, (unsigned) long and int are not equal. The former one has a custom modifier - IsLong.
You can avoid it like the following and it is favorable in this context.
#using <mscorlib.dll>
#include <stdio.h>
#include <windows.h>
using namespace System;
namespace AA
{
public ref class A
{
public:
UINT32 Print()
{
printf("Hello\n");
return 0;
}
};
}
Anyway, I think it is a bug of J# compiler.
Kazuya Ujihara
http://www.ujihara.jp/
Kim Pallister
http://lab.msdn.microsoft.com/productfeedback/default.aspx
mrauch
The problem is not 'unsigned' but 'long'.
It is not solved by removing unsigned word from Goldman's C++ code. VJ# 2005 compiler outputs a wrong CLI at 'a.Print();' line in b.jsl.
It looks like VJ# 2005 doesn't support a custom modifier, which is introduced at .NET Framework 2.0.
I don't know Java language can support primitive type with custom attributes but VJ# has to output an error message at least.
Timm2001
Thanks for filing this bug.
I was wrong last time and am sorry for that. We did some more investigation and now it has become clear that it's a bug on us. We will definitely be fixing it.
Thanks Again.