Add function_internal.hpp to the install interface about casadi HOT 8 CLOSED

function_internal.hpp is part of the internal API, so I don't think it makes sense to have it be an install target. There are also no efforts to keep it stable from one release to another. If you want to couple your tool tightly with CasADi like this, I would suggest you to include CasADi as a git submodule.

from casadi.

Hello,
Thanks a lot for the answer, including it as a git module is not really an option for me because eventually I'd like to make an anaconda build script that is able to integrate a pre-built casadi-python.

I understand that moving the funciton_internal to the public API is not a good idea. I think maybe it is better then to stick to the casadi callback, which is part of the public API. The problem here is that the memory management is problematic for my applications.

The CallbackInternal holds a raw pointer reference to the user-defined Callback. The problem is that it does not take ownership over this resource and that this Callback can be removed from memory while it is still part of a casadi expression / function. This caused segfaults when I implemented callbacks in python as well.

If you this really is a problem (and I'm not using this callback in an unintended way), I can make a different Issue for this and maybe try to see if I can come up with a solution that does not break the current API. Solving this issue would be very useful for me.

from casadi.

The purpose of Callback is really to cater for Python and Matlab users through offering an overloadable interface via swig.
If you are a c/c++ programmer and especially if you are distributing a numerical package tied to casadi, it makes much more sense to work with 'external'. This has a stable API, does reference counting, is efficient, supports codegen, and is robust against mixing binaries compiled with different compilers because the interface is C only.

from casadi.

Agree that using the external C API probably makes more sense. It's more stable, more efficient and also work with things like C code generation. You can probably resolve your persistency issues you're having in Callback by appropriate static method or singleton patterns, but it's probably not worth it if you can just use the C API instead.

from casadi.

Thanks a lot for the recommendations, I'll proceed with the C API. Also thanks for the recommendation of the singleton pattern. I think I'll use that to access my own solver class from the C API implementation. I'll close this issue.

from casadi.

Thanks a lot for the recommendations, I'll proceed with the C API. Also thanks for the recommendation of the singleton pattern. I think I'll use that to access my own solver class from the C API implementation. I'll close this issue.

It's not necessary to use a singleton I think. You should also be able use the "incref/decref/alloc_mem/init_mem/free_mem functions in the C API. But singleton might be easier.

from casadi.

Interesting! Does the int mem arguments in the C API then refer to different instantiations of user-defined function?

Another quick question: is it possible to instantiate a new external Function without having to dl-load a shared library (and going through the file system)? Is it possible to instantiate an external function from c-function pointers to the name_init_mem, name_free_mem, name_release, name_eval ... functions?

Thanks!

from casadi.

Interesting! Does the int mem arguments in the C API then refer to different instantiations of user-defined function?

Correct. This could be useful if you need to evaluate it in parallel for example.

Another quick question: is it possible to instantiate a new external Function without having to dl-load a shared library (and going through the file system)? Is it possible to instantiate an external function from c-function pointers to the name_init_mem, name_free_mem, name_release, name_eval ... functions?

Thanks!

No, I think you need a shared library to use external. Otherwise, you can just use the C API directly. In principle, you could just-in-time compile the function, but this isn't really properly supported.

from casadi.