From: Volker G. <vo...@no...> - 2010-11-03 14:51:21
Attachments:
swig-improved-java-vector.patch
|
Dear SWIG developers, I improved the Java wrapper for std::vector to provide a more "native feeling". In particular, I added: 1) a new constructor for initialization from Arrays: SomeVector(SomeType[] initialElements); 2) a new constructor for initialization from Iterables: SomeVector(Iterable<SomeType> initialElements); 3) an implementation of the Iterable<> interface: SomeVector someVector = new ...; for (SomeType element : someVector) { ... } It would be great if you could include this contribution, as this might be interesting for many others. Although my implementation is far from being perfect, it is still an improvement over the current situation. Also, this might be a starting point for providing similar interfaces to std::map<>, etc. The patch has currently the following (non-critical!) deficiencies which I wasn't able to fix. It would be great to get some help for those from an experienced SWIG developer: A) The added methods are _not_ available automatically when std::vector<SomeType> is instantiated. I simply don't know how to do that using the existing %typemap() infrastructure. Instead, there is a macro CONVENIENT_VECTOR() which adds the interface for a certain type. The macro is automatically called for basic types like "int" and std::string. For a custom class "MyClass" you'll have to add the following code to your *.i file: #ifdef SWIGJAVA CONVENIENT_VECTOR(MyClass) #endif The above lines should always come _before_ the usual template instantiation: %template(MyClassVector) std::vector<MyClass>; B) The additional interface is implemented in pure Java. For 1) and 2), this is to simplify the code, as there isn't much gain in speed to be expected from a native implementation which would have to go through the C interface just to go back to Java iterators etc. via JNI. For 3), there actually _might_ be a performance improvement if the iterator sub class would have been implemented natively. However, subclasses aren't supported by SWIG yet, and I don't know SWIG well enough to create an internal (name mangled) iterator class. That's why I kept it simple, too, providing a plain anonymous Java iterator subclass. C) For vectors of primitive types the Array constructor supports only the corresponding class type. For instance, the wrapper for std::vector<int> provides a constructor IntVector(Integer[] initialElements); but _not_ a constructor: IntVector(int[] initialElements); However, this could be easily fixed in case someone really needs that. Greets, Volker -- Volker Grabsch ---<<(())>>--- |
From: William S F. <ws...@fu...> - 2010-11-11 19:29:24
|
Volker Grabsch wrote: > Dear SWIG developers, > > I improved the Java wrapper for std::vector to provide a > more "native feeling". In particular, I added: > > 1) a new constructor for initialization from Arrays: > > SomeVector(SomeType[] initialElements); > > 2) a new constructor for initialization from Iterables: > > SomeVector(Iterable<SomeType> initialElements); > > 3) an implementation of the Iterable<> interface: > > SomeVector someVector = new ...; > for (SomeType element : someVector) { > ... > } > > It would be great if you could include this contribution, > as this might be interesting for many others. Although my > implementation is far from being perfect, it is still an > improvement over the current situation. > > Also, this might be a starting point for providing similar > interfaces to std::map<>, etc. > > The patch has currently the following (non-critical!) > deficiencies which I wasn't able to fix. It would be > great to get some help for those from an experienced > SWIG developer: > > A) The added methods are _not_ available automatically > when std::vector<SomeType> is instantiated. I simply > don't know how to do that using the existing %typemap() > infrastructure. > > Instead, there is a macro CONVENIENT_VECTOR() which > adds the interface for a certain type. The macro is > automatically called for basic types like "int" and > std::string. For a custom class "MyClass" you'll have > to add the following code to your *.i file: > > #ifdef SWIGJAVA > CONVENIENT_VECTOR(MyClass) > #endif > > The above lines should always come _before_ the usual > template instantiation: > > %template(MyClassVector) std::vector<MyClass>; > > B) The additional interface is implemented in pure Java. > > For 1) and 2), this is to simplify the code, as there > isn't much gain in speed to be expected from a native > implementation which would have to go through the C > interface just to go back to Java iterators etc. via > JNI. > > For 3), there actually _might_ be a performance > improvement if the iterator sub class would have > been implemented natively. However, subclasses > aren't supported by SWIG yet, and I don't know > SWIG well enough to create an internal (name mangled) > iterator class. That's why I kept it simple, too, > providing a plain anonymous Java iterator subclass. > > C) For vectors of primitive types the Array constructor > supports only the corresponding class type. For instance, > the wrapper for std::vector<int> provides a constructor > > IntVector(Integer[] initialElements); > > but _not_ a constructor: > > IntVector(int[] initialElements); > > However, this could be easily fixed in case someone > really needs that. > Looks like you need to use the approaches taken in the csharp/std_vector.i implementation. Note the template specialization and the SWIG_STD_VECTOR_ENHANCED macro used for the primitive types. Also note the $typemap(cstype, CTYPE) special variable macro... you'd need $typemap(jstype, CTYPE) for Java. William |
From: Volker G. <vo...@no...> - 2011-01-04 16:19:54
Attachments:
swig-improved-java-2.patch
|
William S Fulton schrieb: >> >> I improved the Java wrapper for std::vector to provide a >> more "native feeling". [...] > > Looks like you need to use the approaches taken in the > csharp/std_vector.i implementation. Note the template specialization and > the SWIG_STD_VECTOR_ENHANCED macro used for the primitive types. Also > note the $typemap(cstype, CTYPE) special variable macro... you'd need > $typemap(jstype, CTYPE) for Java. Thanks for your advice! I had a look at csharp/std_vector.i and simplified my implementation accordingly. Note that I can't always use "$typemap(jstype, CTYPE)" because this only returns a primitive type (like "int"), where in some places I need the wrapper class (like "Integer"). So I added a new typemap for that purpose: $typemap(jclasstype, CTYPE) I hope the name "jclasstype" is okay, otherwise feel free to rename it. :-) Using that new "jclasstype" typemap I was able to simplify my java/std_vector implementation, and to make it look more similar to csharp/std_vector. I also added another typemap: (char *STRING, size_t LENGTH) That handy typemap is available for almost all languages, but it was missing for Java. It would be great if you could review my patch and include it in SWIG. Greets, Volker -- Volker Grabsch ---<<(())>>--- |
From: William S F. <ws...@fu...> - 2011-01-10 07:56:35
|
On 04/01/11 16:19, Volker Grabsch wrote: > William S Fulton schrieb: >>> >>> I improved the Java wrapper for std::vector to provide a >>> more "native feeling". [...] >> >> Looks like you need to use the approaches taken in the >> csharp/std_vector.i implementation. Note the template specialization and >> the SWIG_STD_VECTOR_ENHANCED macro used for the primitive types. Also >> note the $typemap(cstype, CTYPE) special variable macro... you'd need >> $typemap(jstype, CTYPE) for Java. > > Thanks for your advice! I had a look at csharp/std_vector.i > and simplified my implementation accordingly. > > Note that I can't always use "$typemap(jstype, CTYPE)" because > this only returns a primitive type (like "int"), where in some > places I need the wrapper class (like "Integer"). So I added > a new typemap for that purpose: > > $typemap(jclasstype, CTYPE) > > I hope the name "jclasstype" is okay, otherwise feel free to > rename it. :-) > > Using that new "jclasstype" typemap I was able to simplify > my java/std_vector implementation, and to make it look more > similar to csharp/std_vector. > > I also added another typemap: > > (char *STRING, size_t LENGTH) > > That handy typemap is available for almost all languages, but > it was missing for Java. > > It would be great if you could review my patch and include > it in SWIG. The introduction of a new typemap requires good justification for something that is lacking in the code generation. Here you have used a typemap where you could just use a macro instead. I suggest you use the approach used in arrays_java.i and change your macro to take an additional parameter like this: %define·SWIG_STD_VECTOR_ENHANCED(CTYPE, JAVATYPE) and use it like this: SWIG_STD_VECTOR_ENHANCED(bool, Boolean) I think the char *STRING, size_t LENGTH typemaps belong in java.swg as they look to be globally available in the other languages. William |
From: Volker G. <vo...@no...> - 2011-01-10 09:09:49
Attachments:
swig-improved-java-3.patch
|
William S Fulton schrieb: > Here you have used a > typemap where you could just use a macro instead. I suggest you use the > approach used in arrays_java.i and change your macro to take an > additional parameter like this: > > %define·SWIG_STD_VECTOR_ENHANCED(CTYPE, JAVATYPE) > > and use it like this: > > SWIG_STD_VECTOR_ENHANCED(bool, Boolean) Thanks for your advice. However, I'm somewhat confused, because this is _exactly_ what I did in my first proposal, where you told me to use typemaps instead. I guess I simply misunderstood your first advice. Anyway, I just changed my code back to its original style, using two macros, one for the common case and one for the primitive types: SWIG_STD_VECTOR_ENHANCED(std::string) SWIG_STD_VECTOR_ENHANCED_PRIMITIVE(bool, Boolean) > I think the char *STRING, size_t LENGTH typemaps belong in java.swg as > they look to be globally available in the other languages. Okay, so I moved that code from various.i to java.swg. Is my new patch okay, or are there any other defiances that I should fix? Greets, Volker -- Volker Grabsch ---<<(())>>--- |
From: William S F. <ws...@fu...> - 2011-01-14 19:08:02
|
On 10/01/11 09:09, Volker Grabsch wrote: > William S Fulton schrieb: >> Here you have used a >> typemap where you could just use a macro instead. I suggest you use the >> approach used in arrays_java.i and change your macro to take an >> additional parameter like this: >> >> %define·SWIG_STD_VECTOR_ENHANCED(CTYPE, JAVATYPE) >> >> and use it like this: >> >> SWIG_STD_VECTOR_ENHANCED(bool, Boolean) > > Thanks for your advice. > > However, I'm somewhat confused, because this is _exactly_ what I > did in my first proposal, where you told me to use typemaps instead. > I guess I simply misunderstood your first advice. > That was probably just me not fully comprehending that you have to use boxed types like Integer instead of int in places, sorry. > Anyway, I just changed my code back to its original style, using > two macros, one for the common case and one for the primitive types: > > SWIG_STD_VECTOR_ENHANCED(std::string) > SWIG_STD_VECTOR_ENHANCED_PRIMITIVE(bool, Boolean) > In my original reply, I was hoping you'd use the approach used in the C# version, where you provide template specializations of std::vector for the primitive types. If you can provide a java version of li_std_vector_runme.cs, I'd consider this job done but I think there is a chunk of missing functionality, for example, I'd expect a good implementation to implement the Collection<> and List<> interfaces. William |
From: Volker G. <vo...@no...> - 2011-01-23 01:51:27
|
William S Fulton schrieb: > On 10/01/11 09:09, Volker Grabsch wrote: >> >> Anyway, I just changed my code back to its original style, using >> two macros, one for the common case and one for the primitive types: >> >> SWIG_STD_VECTOR_ENHANCED(std::string) >> SWIG_STD_VECTOR_ENHANCED_PRIMITIVE(bool, Boolean) >> > In my original reply, I was hoping you'd use the approach used in the C# > version, where you provide template specializations of std::vector for > the primitive types. In what important points does my solution differ from the C# version? I thought I did follow that approach as closely as possible - at least I tried to. > If you can provide a java version of > li_std_vector_runme.cs, I'd consider this job done I'm not sure whether I really understand you here. There already exists a li_std_vector_runme.java program. Also, a direct tranlation of li_std_vector_runme.cs to Java is in most points simply impossible, because C#'s and Java's Vector APIs are quite different. So I just added some more test code li_std_vector_runme.java for checking the iterator extension, and added some other tests which I felt were missing: swig-java-vector-1-iterator.patch I also added support for the pointer types: swig-java-vector-2-iterator-ptr.patch > but I think there is > a chunk of missing functionality, for example, I'd expect a good > implementation to implement the Collection<> and List<> interfaces. Note that your request is equivalent to simply demanding the List<> interface, because Collection<> and Iterable<> are superinterfaces of List<>. And although I fully agree that full List<> support would be nice, I don't have the time to do that. This interface is quite big, and there are no helper mechanisms that handle complex methods like subList() for standard cases. Even worse, the already existing methods set(), add() etc. of SWIG aren't compliant to the List<> interface, either. So I went ahead and solved at least that issue, which turned out to be more complicated than expected: swig-java-vector-3-list-compatibility.patch It would be great if you could include those patches #1 - #3. Then, implementing the List<> interface is really "just" adding new methods. I prepared a stub for that, to facilitate the work for others who like to provide the missing methods: swig-java-vector-4-list-stub.patch Note that this patch #4 should *not* be applied to SWIG as it is, because it complies with the List<> interface formally but not sematically (every method throws an UnsupportedOperationException, which is only allowed for a certain subset of them). Greets, Volker -- Volker Grabsch ---<<(())>>--- |
From: William S F. <ws...@fu...> - 2011-01-26 06:35:00
|
On 23/01/11 01:51, Volker Grabsch wrote: > William S Fulton schrieb: >> On 10/01/11 09:09, Volker Grabsch wrote: >>> >>> Anyway, I just changed my code back to its original style, using >>> two macros, one for the common case and one for the primitive types: >>> >>> SWIG_STD_VECTOR_ENHANCED(std::string) >>> SWIG_STD_VECTOR_ENHANCED_PRIMITIVE(bool, Boolean) >>> >> In my original reply, I was hoping you'd use the approach used in the C# >> version, where you provide template specializations of std::vector for >> the primitive types. > > In what important points does my solution differ from the > C# version? I thought I did follow that approach as closely > as possible - at least I tried to. > >> If you can provide a java version of >> li_std_vector_runme.cs, I'd consider this job done > > I'm not sure whether I really understand you here. > > There already exists a li_std_vector_runme.java program. > Also, a direct tranlation of li_std_vector_runme.cs to Java > is in most points simply impossible, because C#'s and Java's > Vector APIs are quite different. > > So I just added some more test code li_std_vector_runme.java > for checking the iterator extension, and added some other > tests which I felt were missing: > > swig-java-vector-1-iterator.patch > > I also added support for the pointer types: > > swig-java-vector-2-iterator-ptr.patch > > >> but I think there is >> a chunk of missing functionality, for example, I'd expect a good >> implementation to implement the Collection<> and List<> interfaces. > > Note that your request is equivalent to simply demanding the List<> > interface, because Collection<> and Iterable<> are superinterfaces > of List<>. > > And although I fully agree that full List<> support would be nice, > I don't have the time to do that. This interface is quite big, > and there are no helper mechanisms that handle complex methods > like subList() for standard cases. > > Even worse, the already existing methods set(), add() etc. of > SWIG aren't compliant to the List<> interface, either. So I > went ahead and solved at least that issue, which turned out > to be more complicated than expected: > > swig-java-vector-3-list-compatibility.patch > > It would be great if you could include those patches #1 - #3. > > Then, implementing the List<> interface is really "just" adding > new methods. I prepared a stub for that, to facilitate the work > for others who like to provide the missing methods: > > swig-java-vector-4-list-stub.patch > > Note that this patch #4 should *not* be applied to SWIG as it is, > because it complies with the List<> interface formally but not > sematically (every method throws an UnsupportedOperationException, > which is only allowed for a certain subset of them). > Indeed, a lot of work is required to get the full IList<> support which I see as the ultimate goal. But given that the interface is going to be quite different to what is currently shipped, I would like the default that SWIG ships either to make no change or get it completely correct because making a non-backwards compatible change that quite possibly may change again in the future is only going to infuriate the many users of std::vector Java wrappers. I suggest you put these patches in the SF tracker as a new patch so that they don't get lost on the mailing list and hopefully someone else can pick them up and finish it off for inclusion into the SWIG distribution. William |
From: Volker G. <vo...@no...> - 2011-01-26 23:54:06
Attachments:
swig-java-vector.patch
|
William S Fulton schrieb: > On 23/01/11 01:51, Volker Grabsch wrote: >> >> And although I fully agree that full List<> support would be nice, >> I don't have the time to do that. This interface is quite big, >> and there are no helper mechanisms that handle complex methods >> like subList() for standard cases. I just noticed that I was wrong. Implementing the List<> interface is much easier than I thought, because there are indeed helper classes. In particular, there is java.util.AbstractList<> which provides everything we need. > I would like the default > that SWIG ships either to make no change or get it completely correct Attached is my proposal for the "completely correct" variant, using java.util.AbstractList<>. Please check whether it meets your requirements. Greets, Volker -- Volker Grabsch ---<<(())>>--- |
[Swig-devel] char *STRING,
size_t LENGTH typemaps. Was [patch] Improved Java wrapper for
std::vector
From: William S F. <ws...@fu...> - 2011-01-14 19:36:13
|
On 10/01/11 09:09, Volker Grabsch wrote: > William S Fulton schrieb: >> I think the char *STRING, size_t LENGTH typemaps belong in java.swg as >> they look to be globally available in the other languages. > > Okay, so I moved that code from various.i to java.swg. > > Is my new patch okay, or are there any other defiances that I should fix? > Thanks, I have committed this and provided a new testcase for it: char_binary.i. Many languages provide support for the (char *STRING, int LENGTH) typemaps which is documented in Library.html. I've also added in the size_t version where there are already int versions. The following mainstream languages are missing this typemap: D, Go, Lua, C#. Could the experts in these languages please provide support for this? The test-suite warns without the typemap. I was thinking about the C# version. Anyone got any thoughts about marshalling this as a C# char[] or byte[]?? William |
From: Ian L. T. <ia...@go...> - 2011-01-14 21:32:00
|
William S Fulton <ws...@fu...> writes: > The following mainstream languages are missing this typemap: D, Go, Lua, > C#. Could the experts in these languages please provide support for > this? The test-suite warns without the typemap. Done for Go. Ian |
From: Volker G. <vo...@no...> - 2011-01-27 00:26:57
Attachments:
swig-java-vector.patch
|
Volker Grabsch schrieb: > Attached is my proposal for the "completely correct" variant, > using java.util.AbstractList<>. Please check whether it meets > your requirements. I just noticed a small mistake in my patch. Attached is the corrected version. Sorry for the inconvenience. Greets, Volker -- Volker Grabsch ---<<(())>>--- |
From: William S F. <ws...@fu...> - 2011-02-03 06:37:35
|
On 27/01/11 00:26, Volker Grabsch wrote: > Volker Grabsch schrieb: >> Attached is my proposal for the "completely correct" variant, >> using java.util.AbstractList<>. Please check whether it meets >> your requirements. > > I just noticed a small mistake in my patch. Attached is the > corrected version. Sorry for the inconvenience. > Thanks. I'll test in due course with a view to committing this after the 2.0.2 release. William |