Is there some place I could get Fortran bindings to Vulkan?
Or do I have to manually write signatures of all C functions?
Related
Where I can find C++ specification for Vulkan (same like the official C one on Khornos pages), describing the particular Vulkan api primitives and functions? Does it even exist (I was trying to find it with no success)?
Personaly I am using the C api even with C++ as I already got used to its style and it fits my needs perfectly (verbose, but you see everything), but I have to go through the code written by other people using C++ api. Usually Vulkan C++ api is just some syntactic sugar build upon the C api function calls, but sometimes digging through vulkan.hpp and trying to figure out what is going on is really annoying.
I am aware of this: https://github.com/KhronosGroup/Vulkan-Hpp
There is no "Vulkan C++ specification". There's a header file containing some functions and types that make using Vulkan more C++-friendly. But those are not part of any actual specification.
The mapping from "VulkanHpp" into regular C Vulkan is pretty obvious in most cases and can be deduced just from the nature of the APIs in question. vk::ImageCreateInfo means the same thing, with the same fields, as VkImageCreateInfo as defined by the Vulkan specification. The C++ wrapper is not trying to confuse users as to how it works.
Is it possible to call a Fortran routine as a Scheme function? I could find nothing by searching the web.
Is it possible? Technically, yes. Most modern Fortran compilers (e.g. ifort, gfortran) support the ISO C Interoperability feature set defined by the Fortran 2003 standard. Thus, it should be possible to write a C compatible API for the fortran libraries you need using the Fortran language. Once you have the C API in place, you should be able to use the standard C FFI provided by your scheme implementation. Of course, all of the usual caveats of calling a C function will also apply here.
The answer depends on which implementation you use.
Here is an example of writing bindings in Racket.
The bindings are for CBLAS and LAPACK. The CBLAS
library is C based and LAPACK is Fortran based.
Therefore you can see both styles.
(Unfinished) Racket bindings for CBLAS and LAPACK
It all depends on your scheme platform. There is nothing regarding FFI (foreign function interface) in the standard per se, but every actual implementation has its own FFI mechanism (if any).
If you're using racket scheme, it appears there is a solution to do so : see http://wmfarr.blogspot.fr/2007/04/linear-algebra-in-plt-scheme.html
This question already has an answer here:
C++ to C Wrapper using SWIG (for FLTK)
(1 answer)
Closed 7 years ago.
I would like to generate C wrappers over some C++ API using SWIG.
From the SWIG documentation SWIG and C++:
6.2 Approach
To wrap C++, SWIG uses a layered approach to code generation. At the lowest level, SWIG
generates a collection of procedural ANSI-C style wrappers. These wrappers take care of
basic type conversion, type checking, error handling, and other low-level details of the
C++ >binding. These wrappers are also sufficient to bind C++ into any target language that
supports built-in procedures. In some sense, you might view this layer of wrapping as
providing a C library interface to C++.
However, I don't see any option to do just that, without generating code for using the API in a language like Python, Ruby, etc. How can I get just the C wrappers?
Although the main branch of SWIG cannot generate C wrappers for C++ API (the SWIG documentation quoted in the question is a bit misleading), there is a SWIG branch created during Google Summer of Code 2008 and available at https://swig.svn.sourceforge.net/svnroot/swig/branches/gsoc2008-maciekd/ which does just that. I have found the answer here: C++ to C Wrapper using SWIG (for FLTK)
if i have written a library in C++, and have bindings for C, Ada, Fortran, D & other compiled languages.
could all these bindings be in the same binary with the C++ compiled code even if they use the same function names?
and could you use the bindings like this?
Depending how you create your bindings a library may not be even necessary:
Bindings written some interpreter specific APIs:
For example, ruby extensions written using the MRI API, are basically a shared library providing a:
void init_Modulename()
This function then uses the MRI api like rb_define_module, rb_define_class, rb_define_method, etc to wrap the C/C++ APIs. Make sure this function is surrounded by extern "C" so it's name does not get mangled in the C++ way.
Normally this shared library goes linked against the library you are binding, but nothing prevents that they are the same shared library.
Bindings done at runtime
For example bindings using FFI on Ruby and other interpreters. The bindings get defined in the same language and it is the FFI library that knows how to call the methods in the target library at runtime. Therefore in this case the bindings themselves have no "library".
Bindings done with generators
If you use a generator, like SWIG, it will scan the library headers and generate the bindings for various languages. Depending on how those targets are implemented by the SWIG generator (for example, for Ruby uses the MRI API described above) then SWIG will create code you can compile into its own library, but as long as you don't have symbol conflicts, you could as well compile this together with your library.
When I mean symbol conflicts, I don't mean the API itself, but the binding helpers, like init_Modulename().
You can link C++ with C, provided you are only calling C style functions (outside of objects) and have turned name mangling off in the header via "extern C". Especially if you are using the same compiler. Different compilers will cause problems if they use different obj formats. I don't know about ADA/Fortran/D, but I suspect the answer will be no, at least directly via .LIB or .OBJ files. On windows, you can try via DLL's if ADA/FORTRAN/D supports dynamic linking (or you can call the windows api LoadLibrary).
This is not an easy thing to do and I glossed over the details. If you are really going to try, then you'll need to be specific about which platforms and compilers you are using and I'll try to be more specific.
Yes. An example (slightly reversed) is PlPlot; it's written in C and has bindings to Ada, C++, D, Fortran77, Fortran95, Java, Lua, OCaml, Python, ...
I have used Lua.NET on .NET platform and I could call the .NET class/object from Lua and I could call the Lua from .NET Lua API interface. I did the same with the IronPython. I knew the how the .NET binding works.
Now I have a C++ project and I want to use the dynamic capabilities. I want to call C++ object which may not be possible from Lua so I may need to call some C API which makes call to C++. Meantime I want to call the Lua from C++.
We have configuration data which is best described in table like format in Lua or List & Dict like in Python. We need to enumerate these data structures defined in Lua/Python in C++.
When considering Lua to Python in C++ for two way calling, is Python have upper hand with Boost Python library? I don't have experience in Python/C++ binding. I don't have equal experience of using Python in C++ and calling Python from C++.
When considering Lua to Python in C++ for two way calling, is Python have upper hand with Boost Python library?
There are a few libraries that simplify the communication between C++ and Lua. One of them, luabind, is inspired by boost.python and is quite powerful and fairly easy to use.
Other C++ <-> Lua libraries to consider: toLua++, SWIG
If you are planning to just use windows you could use C++/CLI a managed variant of C++. With C++/CLI you can easily mix managed and unmanaged code. You could call the managed classes from any .net language and the unmanaged (exported) functions from C.