Duplicate mapping of basic data types
Status: Alpha
Brought to you by:
skieble
Menu
▾
▴
#19 Duplicate mapping of basic data types
Currently the mapping of basic data types (char, int, ...) is given by a configuration file (src/xsl/cpp2j/config.xml). The Mapping of different C++ types to same Java type (unsigned int -> long, long -> long) produces incompilable Java code because of duplicate method declaration. The test t2_3 reproduces this error.
Logged In: YES
user_id=1048110
Originator: NO
IMHO we should solve this problem by ignoring duplicates because of type mappings. Take this example into account:
class MyClass {
long mValue;
void setValue(unsigned int value) { mValue = value; }
void setValue(long value) { mValue = value; }
}
A Java programmer would not be interested in two versions of this function, because it makes no difference to him. If overloaded functions with the same name behave equal can not be said, but good coding style should take care of that. If two functions don't behave equal the names should be different!
Logged In: YES
user_id=1536312
Originator: YES
In my opinion following C++ code is not bad coding style. The write() function generates
different encondings depending on type being called with. So it can be easily used in
template functions (i.e. output operator <<);
clase Encoder {
void write(unsigned char value);
void write(short value);
void write(unsigned int value);
void write(long value);
};
This functionality we could not provide in Java if we ignore duplicates in case
of same type mapping.
Logged In: YES
user_id=1385755
Originator: NO
The problem seems more complicated than in the description.
Before going deep into this problem, i have to mention that the mapping configuration file and the test cases don't cover all C++ basic types.
The following table gives all the basic types i can come up with in C++.
C++ Types Range
bool (false, true)
char (-128 to 127) or (0 to 255) depending on the compiling option
signed char (-128 to 127)
unsigned char (0 to 255)
short (-32,768 to 32,767)
short int same with short
signed short same with short
signed short int same with short
unsigned short (0 to 65,535)
unsigned short int same with unsigned short
int (-2,147,483,648 to 2,147,483,647)
signed same with int
signed int same with int
unsigned (0 to 4,294,967,295)
unsigned int same with unsigned int
long (-2,147,483,648 to 2,147,483,647)
long int same with long
signed long same with long
signed long int same with long
unsigned long (0 to 4,294,967,295)
unsigned long int same with unsigned long
long long (-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807)
signed long long same with long long
unsigned long long (0 to 18,446,744,073,709,551,615)
float IEEE single-precision
doule IEEE double-precision
The following table is the Java basic data types.
Java Types Range
boolean (false, true)
char (0 to 65,535)
byte (-128 to 127)
short (-32,768 to 32,767)
int (-2,147,483,648 to 2,147,483,647)
long (-9,223,372,036,854,775,808 to +9,223,372,036,854,775,807)
float IEEE single-precision
double IEEE double-precision
According to the ranges of these data types, we can get the mapping relation maybe as follows.
C++ Types Mapping to Java
bool boolean
char short
signed char byte
unsigned char char
short short
short int short
signed short short
signed short int short
unsigned short char
unsigned short int char
int int
signed int
signed int int
unsigned long
unsigned int long
long int
long int int
signed long int
signed long int int
unsigned long long
unsigned long int long
long long long
signed long long long
unsigned long long No Java basic data type can cover it. Maybe a class such as BigInteger should be used.
float float
doule double
So we have to face two problems.
1. Some C++ types will be mapped into a same Java type. So duplicate function declarations and definitions will come out.We have to avoid that.
2. The C++ type "unsigned long long" can not be replaced by a Java type. So we have to use a class such as BigInteger to handle it.
Logged In: YES
user_id=1568577
Originator: NO
Do you have already an idea how to solve this? geomap mentioned the possibility of classes for unsigned types (like the Pointer classes). I think such classes should only be used when a method is overloaded. Using that classes always will result in ugly java code, that nobody wants to use. But generating code on demand is somewhat tricky. Now I'm wondering how your solution looks like.
Logged In: YES
user_id=1385755
Originator: NO
Here is my idea.
At first, i will try to mapping all the C++ basic data types to Java data types. Because C++ type "unsigned long long" cannot be mapped into any Java basic data type, i have to use a class as the mapped type of "unsigned long long", maybe BigInteger or another class. So IMHO we have to introduce at least one java class. For the method overloading, i think the best way is use different method names, because several C++ data types will be mapped into a same Java data type as following example.
C++ Java(same method name) Java(different method names)
void Method(unsigned int a); void Method(long a); void Method_I(long a);
void Method(long long a); void Method(long a); void Method_ll(long a);
What do you think?
Logged In: YES
user_id=1568577
Originator: NO
I like the idea of changing method names. But I think it is important to change it only when overloading is used, to keep the original API and to avoid ugly code.
Something similar is already implemented for overloading with const, see t8_?.
In the case:
void a();
void a() const;
We generate in Java:
void a()
void a_const()
But in this case:
void a(int b);
void a(const int b);
We generate just one Java method:
void a(int b)
Logged In: YES
user_id=1385755
Originator: NO
For the case:
void a(int b);
void a(const int b);
If only one Java method is generated, i think it may place a potential problem. Because only one of these two functions will be used, maybe these two functions will perform different operations.
Logged In: YES
user_id=1568577
Originator: NO
I know.
yavin02 has addressed that in his first comment on this bug. We say if overloaded methods are doing differnt things, different names should be used.
Of course we can never be sure that a C++ library follows that principle. But currently we just want to get ogre4j working and not spending much time on general things. If we get problems with that on ogre4j, we can fix it by hand.
Another point is that we don't agree which solution we should take. There is method name changing or creation of additional classes for const or unsigned types. Both are causing differences from the original API and ugly code. Furthermore it can be difficult to do things only when necessary. Thus this wohle thing eats much time and we decided to take care of it later.
To return to this bug:
I think in my previous post the example was not clear enough.
If there is only one const method:
void a() const;
the Java method looks like:
void a()
IMHO for your method name changing it should be the same:
void Method(unsigned int a);
should only get a suffix when it's overloaded.
And
void Method(long a);
should always stay the same.
If I understand your table right, you want to do it this way.
Logged In: YES
user_id=1385755
Originator: NO
OK. I understand we have to take care of ogre4j first and other generic things have the lower priority.
About this bug, i think we reach an agreement. I'm going to split the t2_3 into two cases: one for data type mapping, the other for method overload.
Logged In: YES
user_id=1385755
Originator: NO
I have added a Java class "ULongLong" to cover the C++ basic data type "unsigned long long". By now, all the C++ basic data types can be mapped into Java(test case t2_3). I'm going to create a new test case "t2_9 method overloading" to test the method overloading mechanism.
Logged In: YES
user_id=1385755
Originator: NO
t2_9 is created and tested.
If several functions have same definition, the first one will keep the name and the rest will change the name by appending parameters signatures.
Now there will be no duplicate method definition in Java because of basic data type mapping.
I think this bug is fixed.
Logged In: YES
user_id=1568577
Originator: NO
ohhappyshen fixed this in revision 187.
Logged In: YES
user_id=1385755
Originator: NO
t2_9 is created and tested.
If several functions have same definition, the first one will keep the name and the rest will change the name by appending parameters signatures.
Now there will be no duplicate method definition in Java because of basic data type mapping.
I think this bug is fixed.
Logged In: YES
user_id=1568577
Originator: NO
'const char *' should be mapped to java.lang.String and not org.xbig.base.ShortPointer.
The method std::type_info::name returns a 'const char *'. In fact this is a string but it gets mapped to ShortPointer in Java.
Logged In: YES
user_id=1385755
Originator: NO
That is because c++ type "char" is mapped to java type "short".
I think we can change mapping c++ type "char" to java type "String".
So "char *" will be mapped to java type "String" too.
Logged In: YES
user_id=1048110
Originator: NO
> That is because c++ type "char" is mapped to java type "short".
Why is signed char mapped to jshort? usigned char needs to be mapped to short not char.
> I think we can change mapping c++ type "char" to java type "String".
IMHO this is not a suitable solution. char should be mapped to jchar and char* to jstring. This means that we treat all char pointers as strings and we have to take care about the nil termination of the string. If we have a char[] we should map this to jchararray.
Logged In: YES
user_id=1385755
Originator: NO
IMHO, we have to guarantee the data range of java data type can cover the data range of the corresponding c++ type. So in the current implementation, we have the following mappings.
1) c++ type "char" is mapped to java type "short";
2) c++ type "signed char" is mapped to java type "byte";
3) c++ type "unsigned char" is mapped to java type "short";
Because of the mapping 1), the script thinks "char*" should be translated to ShortPointer. That's obviously incorrect.
I also think map c++ type "char" to java type "String" maybe not a proper solution.
IMHO, maybe we can treat "char*" as a basic type, map it to java type String.
Logged In: YES
user_id=1568577
Originator: NO
We have an inconsistency in config.xml. In C++ (config/cpp/jni/types) types are mapped different as in Java (config/java/types). I agree with the mapping of C++ char to short and byte but I don't think we have to handle char* as a basic type. In config/cpp/jni/types we take care about the passedBy attribute and we should do the same (at least for char) in config/java/types.
Logged In: YES
user_id=1385755
Originator: NO
ok. I understand. I will add passedBy attribute into config/java/types.
Logged In: YES
user_id=1568577
Originator: NO
C++ types int and size_t are mapped to same Java type. We need also a mapping of wchar_t. Are there any more?
Logged In: YES
user_id=1385755
Originator: NO
I think wchar_t can be mapped to java type char, because java type char is 2-Bytes, just like wchar_t.
There is another c++ basic data type "long double", which is not implemented. It's not used in OGRE and there is no corresponding basic data type in Java. So maybe we can leave it after we finish translating OGRE.
Logged In: YES
user_id=1568577
Originator: NO
Yeah, sounds good. So we need:
- char*
- size_t
- wchar_t