Overloaded functions with int and bool parameters don't call the right one

[GoogleCodeExporter]

What steps will reproduce the problem?
1. define the following in a class:

   public native int helloTest(int value);
   public native int helloTest(boolean value);

What is the expected output? What do you see instead?
The output is actually logically correct, but at least on Android jboolean is 
being interpreted as int, so when C++ helloTest gets called it goes to the int 
function.

What version of the product are you using? On what operating system?
SVN 2011/10/25, Win 7 x64, Running on Android 2.3.4

Please provide any additional information below.
I found a way around it. If we cast the boolean in Java [@Cast("bool")] then it 
ends up in the right function. But may be we should cast p0 to bool beforehand 
in generated code?

Original issue reported on code.google.com by bid...@gmail.com on 25 Oct 2011 at 2:47

[GoogleCodeExporter]

Well, primitive types are handled this way on purpose. For example, when we use 
`int` in Java, this actually maps to `jint`, and `boolean` to `jboolean` (which 
is a `typedef unsigned char` and gets interpreted as `int` I guess...) etc. 
This works implicitly for the most part, but sometimes this fails yes, not just 
for `bool`. For example, mapping `long` to `long` with MSVC generates a 
"possible loss of data" warning, but automatically adding a cast to `long` 
would not be a good idea on 32-bit platforms or Windows. In those cases, the 
user should provide the `@Cast`... This is by design.

I find it surprising though that GCC does not generate at least a warning for 
this. Maybe that should be reported to them.

But then again, maybe this perfectly valid C++ according to the standard, along 
with other gems like this one:
http://stackoverflow.com/questions/4111495/why-is-there-an-implicit-type-convers
ion-from-pointers-to-bool-in-c

With C++, the fun never ends... :)

Original comment by samuel.a...@gmail.com on 26 Oct 2011 at 5:09

[GoogleCodeExporter]

So the @Cast workaround is the correct solution?

Original comment by bid...@gmail.com on 26 Oct 2011 at 12:02

[GoogleCodeExporter]

Yes, that would be my assessment. The only thing I am worried about is that we 
don't get a warning about it, something like a "reference to ... is ambiguous" 
error we would get in Java... but in light of the above link, I guess this is 
perfectly normal behavior for C++ :(

Original comment by samuel.a...@gmail.com on 26 Oct 2011 at 12:19

[GoogleCodeExporter]

Ok then. That's good enough for me.

(Is there a Wiki stuff like this could be added to?)

Original comment by bid...@gmail.com on 26 Oct 2011 at 1:48

[GoogleCodeExporter]

Yes, that would be a good idea. Let me know if you would like to add content 
yourself that others could refer to. I could give you access to modify the 
(sort of) wiki pages on this site, thanks.

Original comment by samuel.a...@gmail.com on 27 Oct 2011 at 2:57

• Changed state: Done

[GoogleCodeExporter]

Sure. I can the the few things I have learned. It won't be anything near a full 
documentation but it is a start.

Original comment by bid...@gmail.com on 27 Oct 2011 at 6:42

[GoogleCodeExporter]

Great, thanks! I gave you permission to create and edit "wiki" pages, have fun!

BTW, if there are any other possible issues you are having with JavaCPP, please 
let me know. I think we should make a new "release" with the fixes, thanks.

Original comment by samuel.a...@gmail.com on 28 Oct 2011 at 4:56

[GoogleCodeExporter]

I haven't run into anything else at the moment. All my use cases are working 
properly.

Original comment by bid...@gmail.com on 28 Oct 2011 at 11:51