Hacker News new | past | comments | ask | show | jobs | submit login
How to get started with the LLVM C API (pauladamsmith.com)
65 points by signa11 on Jan 21, 2015 | hide | past | favorite | 12 comments



Their C API is so much cleaner looking than the C++ one, imo. I avoided it so far thinking that once I want to use something not covered in the C API, I don’t want to do a big refactor. Is that a rational fear?


This seems to happen a lot to projects that are written in C++ but have C APIs. Another good example of this would be ZeroMQ. I wonder why this happens.


If I remember correctly from an article many years ago, they want the C++ API to be high-level and fast-moving; the C API exists so that they can support low-level use and almost all clients while only maintaining one API well.


This is a psychological effect caused by some deficiencies in human thinking. People feel obliged to use OOP in full once it is available and shit all over the place with classes, interfaces and inheritance. In a more limited language it is harder to multiply entities, so they just do not do it. So it may make sense to add some artificially crafted pain into a language to force people to write less code.


Interestingly Martin Sustrik, one of the original ZeroMQ authors, expressed regret for having chosen C++ for ZeroMQ.

http://250bpm.com/blog:4 http://250bpm.com/blog:8


And as some of the comments on his blog point out, he uses C++ in a C style.

"If you insist on sticking to a conventional C style of C++ code, you’ll get conventional C-style problems" - Bjarne Stroustrup (http://www.informit.com/articles/article.aspx?p=2080042)


C++ is an awesome languages for writing algorithms and low level memory manipulation, such as network protocols. The big problem is the ABI sucks, although on Linux the story is better than elsewhere. Even on Linux mangling is just confusing.


"The big problem is the ABI sucks"

The problem is that there is no standard ABI call for C++, as implentation is vendor-specific (it may change even for same vendor between different compiler versions (!)). It would be hard to "fix" that, e.g. virtual function tables, exceptions, etc. For standard bindings, C is the only sane option.


I think that is still a valid concern. Features first hit the C++ API and then slowly migrate to a C expressible subset.


I'm really enjoying the proliferation of compiler articles, based on LLVM. I would, however, like to see the other side too: if I write code in C++ or Python, how can I leverage LLVM (and its various compilers) call out to code written in other (possibly brand new) languages?

I really hope we see more DSLs being written, and that it is easy to integrate with them on the back of LLVM.



Thanks, we updated the URL.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: