Use the runtime C++ type when instantiating a pointer

[cypof]

For example in Caffe, Net.layer_by_name tries to create an instance of the root layer class, a java FloatLayer. This class is abstract, so the call fails. How could javacpp find the actual C++ type, and map it to the right java subclass?

[saudet]

I see, there is already some facilities in Generator for this. If the type of the first argument of a native method is Class, it gets used to create the returned object, such as with PointerPointer.get() for example:
https://github.com/bytedeco/javacpp/blob/master/src/main/java/org/bytedeco/javacpp/PointerPointer.java#L308

We could thus declare FloatLayer.layer_by_name() this way and it should work:

public native @Const @Cast({"", "boost::shared_ptr<caffe::Layer<float> >"}) @SharedPtr @ByVal L layer_by_name(Class<L extends FloatLayer> cls, @StdString String layer_name);

We could simply put that in the presets, if it works. How does that sound? BTW, I don't feel it would be a good idea to hack something together to try to detect automatically the type, since in C++ we have to cast explicitly anyway. It seems hard to justify how we can safely do this without any explicitly cast. (Not that converting the pointer to long as is is guaranteed to be any safer, but at least we are not influencing the final user API in Java.)

[cypof]

Thanks, that should fix the issue for now, by passing e.g. FloatMemoryDataLayer.class as argument. For the general case though, I am not sure I understand what you mean with the explicit cast.

The example I'm thinking of is let's say a C++ method with a Layer* return type. At runtime, for a particular execution, it returns a pointer to a MemoryDataLayer object. It seems to me that the right thing to do would be to get the typeid, and have javacpp map to the the right java class at runtime. So that is can instantiate a FloatMemoryDataLayer object, even if the java method has a return type of FloatLayer.

[saudet]

C++ doesn't support reflection, so we need to create a bunch of if statements that checks with dynamic_cast<>, but if we were to use it from C++, we would usually have a good idea of the type, and would not need to do that, right? That said, the best way to map that might be to NOT make abstract FloatLayer, or any other peer class for that matter... What do you think?

[cypof]

I believe there is this "typeid" feature that might help, that might be enough as you know the mapping in advance. But I haven't played with it at all.

[saudet]

Right, there's typeid, thanks for reminding me. But then, we are limiting the supported types to the ones we know at compile time, unless we provide some way to register C++ types at runtime, but there's no way to automate that, AFAIK? This is getting complicated. I think in the end we should allow users to create instances of FloatLayer, for example, and let them cast that to something else, if required.

[saudet]

Ok, modifications done! Let me know if that is working satisfactorily. Thanks for reporting!

[cypof]

Yes that's simpler and should work for us, thanks. I believe that in the long run it might interesting to support type mapping, e.g. if you call net.layers() to get the full network for manipulation or visualization, if the layers have the right type already it would be simpler. Otherwise the java side needs to parse the proto file too, to know which layer is of what type etc. But there is no need right now, just to keep in mind.

[saudet]

I'm sure it would make things easier down the road if we can figure out the type, but C++ doesn't offer much in that way. BTW, in C++, when calling net.layers(), how do people go about it? Maybe it would make most sense to figure out a way to wrap that particular idiom...