Live data from Hacker News

C++ Language Interface Foundation (CLIF)

github.com

1–10 of 72 posts

Re: C++ Language Interface Foundation (CLIF)

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

Re: C++ Language Interface Foundation (CLIF)

#5
Having trouble groking this. Can someone give a simple use case / example? If the Parser generates language agnostic data, how can this data be passed to the Matcher which parses C++ headers (i.e., C++ headers are not language agnostic).

A good README should give a "high level" description of what the things is and what its used for.

Re: C++ Language Interface Foundation (CLIF)

#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)

Re: C++ Language Interface Foundation (CLIF)

#7
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)

Doesn't the IDL approach require that the declarations/intermediate language be written manually though? Most C++ libraries out there don't have any IDL files (looks at QT)

Re: C++ Language Interface Foundation (CLIF)

#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 very easily. I imagine the latter problem has only gotten worse with heavier use of templated types in APIs. It looks like CLIF doesn't expose the template per se (at least in the Python examples) but requires explicit instantiation of each specialization as a distinct Python class. Templates mess with the very concept of an FFI generator, which tends to assume a reasonably clear separation between compile time and run time (so you don't need to run a C++ compiler as a pre-pass on any code that uses a binding).

All that is a roundabout way of saying: for god's sake write your system APIs in C.

Re: C++ Language Interface Foundation (CLIF)

#9
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.

Re: C++ Language Interface Foundation (CLIF)

#10
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)

Doesn't the IDL approach require that the declarations/intermediate language be written manually though? Most C++ libraries out there don't have any IDL files ( looks at QT )

I mean IDL-like, as in valid c++ that is almost as easy to read as an IDL (to me at least) but without losing the ability to dive in to the binding if necessary. If you're trying to produce a binding that feels idiomatic in the target language, I'd say this is important, and this is where Swig-like approaches show their weakness.

I think the author of Swig shares this sentiment: (http://code.activestate.com/lists/python-dev/109281/).

Post reply on HN