Sort out C# and Java bindings to avoid SWIGTYPE

[Olly Betts]

The SWIGTYPE_p_*.cs files are C# wrappers around raw C/C++ types, which can't be naturally used from C#. We should adjust the bindings to wrap these properly.

The same issue affects our Java bindings too.

[Olly Betts]

r16251 removes two of these (for trunk) - so currently we only have SWIGTYPE_p_std__string.cs, which is presumably from ValueRangeProcessor::operator() which takes two std::string & arguments.

[Olly Betts]

In git master RangeProcessor has replaced ValueRangeProcessor and returns a Query object, so that one is gone now.

$ rgrep SWIGTYPE generated-csharp/*.cs
generated-csharp/Compactor.cs:  public virtual string ResolveDuplicateMetadata(string key, uint num_tags, SWIGTYPE_p_std__string tags) {
generated-csharp/Compactor.cs:    string ret = (SwigDerivedClassHasMethod("ResolveDuplicateMetadata", swigMethodTypes1) ? XapianPINVOKE.Compactor_ResolveDuplicateMetadataSwigExplicitCompactor(swigCPtr, key, num_tags, SWIGTYPE_p_std__string.getCPtr(tags)) : XapianPINVOKE.Compactor_ResolveDuplicateMetadata(swigCPtr, key, num_tags, SWIGTYPE_p_std__string.getCPtr(tags)));
generated-csharp/Compactor.cs:    return ResolveDuplicateMetadata(key, num_tags, (tags == global::System.IntPtr.Zero) ? null : new SWIGTYPE_p_std__string(tags, false));
generated-csharp/Compactor.cs:  private static global::System.Type[] swigMethodTypes1 = new global::System.Type[] { typeof(string), typeof(uint), typeof(SWIGTYPE_p_std__string) };
generated-csharp/QueryParser.cs:  public void AddBooleanPrefix(string field, string prefix, SWIGTYPE_p_std__string grouping) {
generated-csharp/QueryParser.cs:    XapianPINVOKE.QueryParser_AddBooleanPrefix__SWIG_0(swigCPtr, field, prefix, SWIGTYPE_p_std__string.getCPtr(grouping));
generated-csharp/QueryParser.cs:  public void AddBooleanPrefix(string field, FieldProcessor proc, SWIGTYPE_p_std__string grouping) {
generated-csharp/QueryParser.cs:    XapianPINVOKE.QueryParser_AddBooleanPrefix__SWIG_3(swigCPtr, field, FieldProcessor.getCPtr(proc), SWIGTYPE_p_std__string.getCPtr(grouping));
generated-csharp/QueryParser.cs:  public void AddRangeprocessor(RangeProcessor range_proc, SWIGTYPE_p_std__string grouping) {
generated-csharp/QueryParser.cs:    XapianPINVOKE.QueryParser_AddRangeprocessor__SWIG_0(swigCPtr, RangeProcessor.getCPtr(range_proc), SWIGTYPE_p_std__string.getCPtr(grouping));
generated-csharp/SWIGTYPE_p_std__string.cs:public class SWIGTYPE_p_std__string {
generated-csharp/SWIGTYPE_p_std__string.cs:  internal SWIGTYPE_p_std__string(global::System.IntPtr cPtr, bool futureUse) {
generated-csharp/SWIGTYPE_p_std__string.cs:  protected SWIGTYPE_p_std__string() {
generated-csharp/SWIGTYPE_p_std__string.cs:  internal static global::System.Runtime.InteropServices.HandleRef getCPtr(SWIGTYPE_p_std__string obj) {

So the current uses are:

• Compactor::resolve_duplicate_metadata()'s tags parameter - this is a fairly obscure feature, but ideally num_tags and tags should map to some sort of ordered container of strings in the bindings.
• The grouping parameter to QueryParser::add_boolean_prefix() and QueryParser::add_rangeprocessor() - this is essentially a nullable string parameter, so that's how it should be wrapped for the bindings.

[Olly Betts]

15c8ee918667d3af965ebcf55cc585d6aeffcdc1 wraps the const std::string* parameters to accept a C# string or null - that just leaves Compactor::resolve_duplicate_metadata() to deal with.

[Olly Betts]

Java has the same issues, and I've addressed const std::string* wrapping there in the same way as for C++ in c77630eee1da068c7a6a2009011b7d10e2b8a999.

[Olly Betts]

I've backported the C# and Java const std::string* parameter handling improvements ready for 1.4.18 in 5fb3813fa9d7cc30a0ada78bef17d9d032f2aceb and c5e3a43220a551813beb61ad2601e364802f5663.

In git master, only the Compactor::resolve_duplicate_metadata() use is still to deal with (for both C# and Java).

In 1.4 there's also ValueRangeProcessor and subclasses, but those are deprecated in 1.4 and gone in git master so I don't think it's worthwhile changing them now.

[Olly Betts]

It would be good to resolve this, but it's only one obscure method which is affected so postponing for now.