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

51–60 of 72 posts

Re: C++ Language Interface Foundation (CLIF)

#51

Post by gumby »

inetknght wrote: post #29
gpshead wrote: post #14

I wondered how long it would take before someone posted CLIF here since we haven't put up a blog post about it yet... :) Interesting stat: Around 80% of our the Python C++ extension module wrappings being added to our code base are now being done using CLIF instead of SWIG. We are actively working on forbidding new Python SWIG wrappers from being added and migrating important legacy wrappings off of it onto CLIF. Who…

So... someone with basically zero Python experience and a ton of C++ experience could basically "hand that experience down" to his newly minted Python-self?

Sounds like a worthy goal. There will always be infelicities (as with human language translation as well) but why not?

Re: C++ Language Interface Foundation (CLIF)

#52

Post by mountain_lion »

ithkuil wrote: post #37
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…

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

I was in the room when this person said it (and it was in the context of CLIF's Google-wide adoption), so I think it's reasonable that my interpretation that this was a positive statement is reasonable.

At least if you weren't in the room as well. I'm assuming you weren't?

Re: C++ Language Interface Foundation (CLIF)

#53

Post by mountain_lion »

stinos wrote: post #43
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…

CLIF is used inside Google for some very non-trivial projects.

Re: C++ Language Interface Foundation (CLIF)

#54

Post by dom0 »

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…

COM works remarkably well (and a ton of system APIs simply doesn't exist as a C API). It probably only gets bashed because some people conflate it with DCOM and it's security issues.

Re: C++ Language Interface Foundation (CLIF)

#55

Post by mish33 »

cjhanks wrote: post #4

I like this idea, I will try this soon. Is there any plan for somewhat transparently supporting NumPy?

NumPy support is a borderline issue for CLIF.

Typical usage I saw is the following: C++ has some class(es) that best represented as NumPy arrays. So because those classes are specific to the project (not generic like std::) they don't fit into CLIF runtime, but the project supply a C++ library with custom conversion functions as described in ext.md that use NumPy C API tells CLIF that those classes are convertible to Python objects (that NumPy objects are).

That all NumPy integration CLIF needs and it has to come from the user.

Re: C++ Language Interface Foundation (CLIF)

#56

Post by mish33 »

gumby wrote: post #50
gumby wrote: post #40

Earlier quoted context omitted.

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

A C++ header file is full of garbage^W implementation details and not-C++ users want a stable API definition - that's what .clif file is about. It's an interface declaration for a native user.

Re: C++ Language Interface Foundation (CLIF)

#57

Post by mish33 »

obstinate wrote: post #25
gpshead wrote: post #14

I wondered how long it would take before someone posted CLIF here since we haven't put up a blog post about it yet... :) Interesting stat: Around 80% of our the Python C++ extension module wrappings being added to our code base are now being done using CLIF instead of SWIG. We are actively working on forbidding new Python SWIG wrappers from being added and migrating important legacy wrappings off of it onto CLIF. Who…

When are y'all doing Go and Java, though? The fact that this exists just compounds the pain of writing SWIG for the other two languages. The grass really is greener.

Go and Java claimed they can do without C++, so let them suffer :)

It takes time and because we love Python we did it first. Others will come.

Re: C++ Language Interface Foundation (CLIF)

#58

Post by m-j-fox »

pjmlp wrote: post #45
m-j-fox wrote: post #9

Earlier quoted context omitted.

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.

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.

Re: C++ Language Interface Foundation (CLIF)

#59

Post by chubot »

atilaneves wrote: post #47
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…

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

OK, good to know about D.

As far as zero cost, my understanding is that D is still trying to get rid of GC from the standard library.

And I'm explaining why I think Rust is having a hard time getting adoption. It makes an effort to be compatible with C, but not with C++. But really C++ is its "competitor", not C.

And C++ has the network / lock-in effect I described. All languages have a network effect to some degree (libraries, documentation), but I think the situation with C++ is especially acute.

Also, I would say that safety and zero-cost abstractions are the goal of Rust. Those two goals conflict somewhat -- e.g. in the decision over bounds checking. Although I guess you can say that without bounds checking you have no abstraction; you just have a pile of buggy code at zero cost :)

Re: C++ Language Interface Foundation (CLIF)

#60

Post by mountain_lion »

gumby wrote: post #50
gumby wrote: post #40

Earlier quoted context omitted.

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

#pragmas are not portable, and have various problems with compatibility.

Structured comments could work, but because the C++ compiler doesn't parse them, you essentially have a file-with-a-file, and 80% of the problems you encounter with the dual-file system.

You also have the problem of the API's client trying to understand what the API looks like. We don't want to make them read C++ code in any way, and a pyclif file looks a lot like python.

Finally, CLIF is substantially more terse than SWIG--on the order of 1/10th the number of lines. This makes it less of a big deal to have a separate file.

Post reply on HN