containers: vectors of pairs not properly generated

[HGuillemet]

Parser generates code for pairs and not for vectors for vectors of pairs.
Example for std::vector<std::pair<int, X>>:

public class XPairVector extends Pointer {
    static { Loader.load(); }
    /** Pointer cast constructor. Invokes {@link Pointer#Pointer(Pointer)}. */
    public XPairVector(Pointer p) { super(p); }
    public XPairVector(int[] firstValue, X[] secondValue) { this(Math.min(firstValue.length, secondValue.length)); put(firstValue, secondValue); }
    public XPairVector()       { allocate();  }
    public XPairVector(long n) { allocate(n); }
    private native void allocate();
    private native void allocate(@Cast("size_t") long n);
    public native @Name("operator =") @ByRef XPairVector put(@ByRef XPairVector x);

    public boolean empty() { return size() == 0; }
    public native long size();
    public void clear() { resize(0); }
    public native void resize(@Cast("size_t") long n);

    @Index(function = "at") public native int first(@Cast("size_t") long i); public native XPairVector first(@Cast("size_t") long i, int first);
    @Index(function = "at") public native @ByRef X second(@Cast("size_t") long i);  public native XPairVector second(@Cast("size_t") long i, X second);

    public XPairVector put(int[] firstValue, X[] secondValue) {
        for (int i = 0; i < firstValue.length && i < secondValue.length; i++) {
            first(i, firstValue[i]);
            second(i, secondValue[i]);
        }
        return this;
    }
}

This is due to these lines. firstType and secondType being tested here for generating the code of pairs.

What about adding condition dim == 0 line 221 ?
Or maybe removing condition indexType != null line 355 ?

[saudet]

That's intentional... What's the issue?

[HGuillemet]

Sorry. I expected a vector interface for a vector of pairs. I didn't see the index argument of first and second.

But there is a little issue: how to map a c++ function returning a std::vector<std::pair<..>>::iterator ?

In Pytorch, this is the case of ParameterListImpl for instance.

In the current version of the presets, you seem to use some workaround where the iterator, and the item are mapped to the same class.

[saudet]

It's not exactly a workaround, JavaCPP just isn't able to resolve the correspondence, but if you follow the typedefs and what not, that's what the type of the iterator ends up being.

[HGuillemet]

But with additional functions used for iterating that we cannot map (increment and comparison operators).
Without them, I guess we can still iterate using ParameterListImpl.size() and StringTensorPair.position(n) on the StringTensorPair returned by begin()

[saudet]

We could add those functions too if that's what you're looking for.

[HGuillemet]

I think it would be a good thing.

[HGuillemet]

And maybe also add a mapping for front and back to preserve the option of getting first and last item with a single call ?