Fellows, I would suggest you check https://github.com/mono/CppSharp. It's Clang-based as well and despite the name, it's not bound to C# or .NET, generators for any languages can be added. It's feature complete with the exception of templates which are being worked on as we speak. It's also fully automated, manual intervention is only required if the user wants binding-specific customisation.
C++ Language Interface Foundation (CLIF)
61–70 of 72 posts
Re: C++ Language Interface Foundation (CLIF)
#62Fellows, I would suggest you check https://github.com/mono/CppSharp. It's Clang-based as well and despite the name, it's not bound to C# or .NET, generators for any languages can be added. It's feature complete with the exception of templates which are being worked on as we speak. It's also fully automated, manual intervention is only required if the user wants binding-specific customisation.
Re: C++ Language Interface Foundation (CLIF)
#63Earlier quoted context omitted.
Modern C++ means picking up the ideas from Alexandrescu, avoiding unsafe C style programming unless profiler tells otherwise and using the higher level features from C++ for writing nice, usable, safe libraries. Many of the idioms actually already possible back in the C++ARM days, before C++98 was a thing, but spoiled by C refugees.
Maybe I got my terminology wrong. I'm talking about the wave of new standards. I feel like they're a bunch of new languages which are improvements over C++ but not backwards compatible with C++. Every problem you have interoperating two different languages you have between these different C++es but worse because there aren't tools like SWIG to help you.
You can say the same about any programming language that enjoys wide market adoption, except maybe for C that still thinks computers are like PDP-11's, with C99 and C11 being very tiny evolutions with little regard to improve the overall productivity.
Even Fortran and Cobol(!) have evolved more than C.
Re: C++ Language Interface Foundation (CLIF)
#64Earlier quoted context omitted.
> I find manual work required by the latter to be 100% worthwhile and usually necessary Roughly the same experience. Automatic generation for anything more than trivial examples always seems to lead to the need for more and more configuration to keep everything in line, to the point where just writing everything by hand becomes less work. This is likely due to the type of software we use it for, but still, the amount…
CLIF is used inside Google for some very non-trivial projects.
Well I'm always open to new ways of doing things. Any estimate of how hard it would be to generate MicroPython [1] wrappers for C++ code (in a rather configurable way as described earlier)?
Re: C++ Language Interface Foundation (CLIF)
#65Earlier quoted context omitted.
CLIF does recognize explicit template instatiations, and can instantiate a limited set itself. There is no pain like keeping the two files in sync because clif only allows a very small amount of C++ in its sources--basically just type names. And cliff takes care to error out when the wrapper description doesn't match the C++. "When in doubt, refuse the temptation to guess." Our internal clients really like it. Someon…
"magic" is an overloaded term. In can mean something so beautifully advanced that you cannot distinguish it from advanced tech and you really don't care how it works, since it works so flawlessly you couldn't bother looking behind the scenes. I.e. a praise. Or it can mean something that uses some arcane unearthly constructs and at the moment you need to look behind the scenes you find yourself utterly lost. I.e. a cr…
No goats need to be sacrificed in order for CLIF to do the right thing.
Re: C++ Language Interface Foundation (CLIF)
#66Earlier quoted context omitted.
CLIF is used inside Google for some very non-trivial projects.
Well I'm always open to new ways of doing things. Any estimate of how hard it would be to generate MicroPython [1] wrappers for C++ code (in a rather configurable way as described earlier)? [1] https://github.com/micropython/micropython
It seems entirely reasonable for someone to create a MicroPython wrapper generator. It appears to have a C/C++ API so it should be similar to the existing CPython Generator and Runtime.
Re: C++ Language Interface Foundation (CLIF)
#67Earlier quoted context omitted.
Metaprogramming such as pybind11 does is neat. Thanks for the pointer to the project. It still looks like manually written C extension modules to me based off of what I see in https://github.com/pybind/pybind11/blob/master/docs/basics.r... . Just much shorter code with a lot of the hard to get right details taken care of you. Good! Better than the status quo. But it doesn't abstract the problem away very much. (no do…
Semi-related, in case you haven't seen it: http://doc.pypy.org/en/latest/cppyy.html
Thanks! Eek! An XML interface definition. In 2017!
Re: C++ Language Interface Foundation (CLIF)
#68There are several issues that I usually hit with bindings to C/C++ and other languages: - Calling a native function that itself takes callback, and that callback might be your non-native code. (trampolines?) - Dealing with memory allocation. Who owns what. - Exceptions or long_jmps - Green threads, fibers, etc. - Other?
callbacks in swig are straightforward. you have a C/C++ reciver function that gets registered along with a pointer to the scripting language target function. I've used this design for over a decade.
I was mentioning FFI in general, like Common Lisp's FFI, LuaJIT, others. For example for callback back, you need to have a trampoline, where the "C/C++" trampoline would call back your language runtime "engine". But this introduces gap in the "stack", and might not work with all VM's, or you may run out of trampoline slots, and not being able to allocate new, since this would require dynamic code generation, and say on iOS and certain other game consoles that's not allowed.
Re: C++ Language Interface Foundation (CLIF)
#69Earlier quoted context omitted.
callbacks in swig are straightforward. you have a C/C++ reciver function that gets registered along with a pointer to the scripting language target function. I've used this design for over a decade.
I was mentioning FFI in general, like Common Lisp's FFI, LuaJIT, others. For example for callback back, you need to have a trampoline, where the "C/C++" trampoline would call back your language runtime "engine". But this introduces gap in the "stack", and might not work with all VM's, or you may run out of trampoline slots, and not being able to allocate new, since this would require dynamic code generation, and say…
there are no trampoline slots required. it's a function pointer that's provided as an argument (user data). Can you point to an FFI that doesn't support callbacks in this way? This would be a major problen in the FFI implementation.
Re: C++ Language Interface Foundation (CLIF)
#70Earlier quoted context omitted.
I was mentioning FFI in general, like Common Lisp's FFI, LuaJIT, others. For example for callback back, you need to have a trampoline, where the "C/C++" trampoline would call back your language runtime "engine". But this introduces gap in the "stack", and might not work with all VM's, or you may run out of trampoline slots, and not being able to allocate new, since this would require dynamic code generation, and say…
there are no trampoline slots required. it's a function pointer that's provided as an argument (user data). Can you point to an FFI that doesn't support callbacks in this way? This would be a major problen in the FFI implementation.
LuaJIT limits both the number of registered callbacks [1], and re-entering the interpreter from a JIT'd callback [2] (it will try to detect and prevent JIT for such functions, but if that fails you get a panic).
[1] http://stackoverflow.com/questions/31042530/why-does-luajit-...
[2] http://stackoverflow.com/questions/25924755/c-and-lua-unprot...