Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ Language Interface Foundation (CLIF)

github.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: C++ Language Interface Foundation (CLIF)

#41

Post by chubot »

pjmlp wrote: post #38
chubot wrote: post #21

Earlier quoted context omitted.

Yeah I've grown to appreciate C++ in many ways, but what I noticed at my last job is that the baroque interfaces give it a viral effect. Once you have a little C++ code, the easiest thing to do is to continue writing more C++ code, even if it's not the best tool for that job. It's too hard to use a C++ interface from any other language. Even wrapping it in C is annoying, although as I understand LLVM does exactly tha…

> C++ is sort of like a universal receiver and not a universal donor. It can assimilate any C code... This is part of the language's design. Bjarne's goal after being forced to use BCPL instead of Simula was never to use a bare bones language ever again, and C with Classes needed to fit into AT&T's C tooling. Hence why we also didn't got modules back then and a funky name mangling to fit into those bare UNIX linkers.…

Yeah I read "The Design and Evolution of C++" and quite liked it. His goal was definitely to assimilate C code, with compatibility being a high priority.

But I'm not sure the goal was to make C++ hard to use from other languages. I think that just fell out of the focus on zero-cost abstractions.

COM seems like the right middle ground between baroque C++ interfaces and RPC/message passing. You write native code, but it can interoperate dynamically with components in other languages, in the same address space. But I think it is overly tied to OOP, and that doesn't play well with the style of Unix.

I wonder if it would be possible to do better, or if that ship has sailed. I'm not overly familiar with Windows... I know there were some problems with COM but it seemed basically sound. I used JScript once and it was pretty powerful.

Re: C++ Language Interface Foundation (CLIF)

#42

Post by pjmlp »

chubot wrote: post #41
pjmlp wrote: post #38

Earlier quoted context omitted.

> C++ is sort of like a universal receiver and not a universal donor. It can assimilate any C code... This is part of the language's design. Bjarne's goal after being forced to use BCPL instead of Simula was never to use a bare bones language ever again, and C with Classes needed to fit into AT&T's C tooling. Hence why we also didn't got modules back then and a funky name mangling to fit into those bare UNIX linkers.…

Yeah I read "The Design and Evolution of C++" and quite liked it. His goal was definitely to assimilate C code, with compatibility being a high priority. But I'm not sure the goal was to make C++ hard to use from other languages. I think that just fell out of the focus on zero-cost abstractions. COM seems like the right middle ground between baroque C++ interfaces and RPC/message passing. You write native code, but i…

Well UWP is basically the COM+ Runtime reborn, picking up the ideas that they were discussing back when Ext-VOS was being planned, which eventually became .NET instead.

OS/2 SOM was better in that it supported implementation inheritance and meta-classes.

Apple also had some nice ideas for Copland and how to further develop Taligent, but there is little documentation left of that effort.

Re: C++ Language Interface Foundation (CLIF)

#43

Post by stinos »

jzwinck wrote: post #12

Having used both SWIG and Boost.Python professionally, I find manual work required by the latter to be 100% worthwhile and usually necessary. C++ and Python are not very similar, and the result of auto-binding them typically gives up a combination of fluency and performance. A simple example of the former is a C++ algorithm which writes to an output iterator. In Python this might be expressed as a generator. But none…

> 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 of time I lost on SWIG really seems wasted instead of leaving the feeling of having learnt at least something. It was all not very pleasant. The Python side of our software gets exposed to less tech-savvy users and is meant to be a more friendly layer over C++ functions and classes. But the C++ side isn't really an API in the sense there is no hard distinction between the 'internal' layer and the API layer. Some class which is only used internally might the next day also be wrapped to be available in Python. So there's no single directory or so one can point to and say 'everything in there is the API'. Also given a C++ class, sometimes only a couple of methods have to get exposed to the users, sometimes with a different name even, or some arguments defaulted etc. Preferrably without having to write a wrapper just for the sake of exposing it. All this turned out to be a nightmare in SWIG. Just manually writing one or more lines for registering the function manually (not Boost.Python but similar) is usually a one-time-almost-never-look-back thing which, for us, is way less work in the end. Even with the hundreds of functions we have already. And of course performance is the other advantage.

Re: C++ Language Interface Foundation (CLIF)

#44

Post by snowAbstraction »

Cieplak wrote: post #36
chubot wrote: post #21

Earlier quoted context omitted.

Yeah I've grown to appreciate C++ in many ways, but what I noticed at my last job is that the baroque interfaces give it a viral effect. Once you have a little C++ code, the easiest thing to do is to continue writing more C++ code, even if it's not the best tool for that job. It's too hard to use a C++ interface from any other language. Even wrapping it in C is annoying, although as I understand LLVM does exactly tha…

I quite like using Erlang/OTP to host C++ nifs. I feel like it strikes that 10% of code being in C++ balance that you mentioned. I heard it's a popular combo for HFT applications. http://erlang.org/doc/tutorial/nif.html

The linked to page only shows C and not C++.

Re: C++ Language Interface Foundation (CLIF)

#45

Post by pjmlp »

m-j-fox wrote: post #9
gumby wrote: post #3

Finally! I have been suffering under SWIG and have been hoping for some time that someone would get the compiler to do this.+ Not to say SWIG isn't an amazing effort, but it's a whole C++ compiler maintained by a very small team. + I already put my time in at the gcc salt mines so no, I didn't try doing this myself.

I'm cautiously excited. The problem with C++ is there's just so many good frameworks but you can't use them without creating more C++. SWIG should be called WIG. And anyway, I can't see it surviving modern C++. As long as I'm ranting, what is modern C++ but a bunch of new languages that are incompatible with C++, each other, and everything else? Forgive me if I'm wrong but this seems like a terrible idea.

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.

Re: C++ Language Interface Foundation (CLIF)

#46

Post by zeptomu »

jzwinck wrote: post #12

Having used both SWIG and Boost.Python professionally, I find manual work required by the latter to be 100% worthwhile and usually necessary. C++ and Python are not very similar, and the result of auto-binding them typically gives up a combination of fluency and performance. A simple example of the former is a C++ algorithm which writes to an output iterator. In Python this might be expressed as a generator. But none…

Assuming one wants to call C++ code from Python (the common case) I would even start with simple pipe-based IPC and just build an executable in C++ that acts as a bridge between Python (or any other language in this case) and C++. E.g. using JSON serialization it would look like this:

  $LANG (e.g. Python)  JSON  Pipe  JSON  C++
If this is too slow I still wouldn't use a binding generator (SWIG, etc.), but build a C API using opaque pointers that offer the required functions, i.e. a bridge between C and C++. Finally one can simply call into this API with Python's ctypes which are part of its standard library.

  Python  ctypes  C-API  C++
I have worked previously with SWIG, but my experience has been very bad, in particular the problem with binding generators is similar to the problem parser generator face - they make the simple stuff simple and the hard stuff hard. Furthermore the bindings that are auto-generated are mostly too low-level, so one normally writers wrappers around them to make them more "pythonic" which raises the questions why not write the bindings from scratch anyway?

Re: C++ Language Interface Foundation (CLIF)

#47

Post by atilaneves »

chubot wrote: post #21
rayiner wrote: post #8

C++ is an extremely challenging language to write a wrapper generator for. I did a C++ to Common Lisp generator about a decade ago for my GSoC project, based on GCC-XML (with the goal of being able to wrap QT). The two challenges you run into are that the GCC C+ ABI is extremely complicated and requires a runtime on top of whatever low-level C FFI you're working with. The second is that many semantics just don't map…

Yeah I've grown to appreciate C++ in many ways, but what I noticed at my last job is that the baroque interfaces give it a viral effect. Once you have a little C++ code, the easiest thing to do is to continue writing more C++ code, even if it's not the best tool for that job. It's too hard to use a C++ interface from any other language. Even wrapping it in C is annoying, although as I understand LLVM does exactly tha…

> It's too hard to use a C++ interface from any other language.

D has the best support for this. It's not as simple as `#include ` but it's better than any other language at it. Name mangling matches, C++ exception support and C++ abstract classes can be declared as D interfaces and everything works.

> C++ really is unique in terms of offering zero-cost abstraction

Rust and D (at the very least) would disagree.

Re: C++ Language Interface Foundation (CLIF)

#48

Post by ihnorton »

gpshead wrote: post #26
krona wrote: post #6

The repository mentions "other languages" but I could only find Python examples? While I think wrapper generators are a noble idea, I doubt I would choose this over the convenience of IDL-like metaprogramming approaches (e.g. pybind11, or Boost.Python)

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

Re: C++ Language Interface Foundation (CLIF)

#49

Post by dekhn »

malkia wrote: post #23

There 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.

Re: C++ Language Interface Foundation (CLIF)

#50

Post by gumby »

gumby wrote: post #40
mountain_lion wrote: post #32

Earlier 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…

Why do you need a handwritten clif file?

Why would this be down voted? It's a legit question, and a followup in the comment chain.

I understand why SWIG needs a .i file, as it doesn't understand much about the code. But when you control the compiler you can 1> as in the example I gave, look at actual explicit instantiation instead of doing the synthetic thing SWIG does, as well as make other, smarter decisions and 2> use #pragmas or attributes to direct translation at the point of use.

And the author even said himself that "code two files is a pain."

Thus my question remains: why the need for a .clif file?

Post reply on HN