This discussion piqued my interest, and I decided to see what I could do to make rsc.io/c2go <http://rsc.io/c2go> more general-purpose. My fork is at github.com/andybalholm/c2go <http://github.com/andybalholm/c2go>. I think that, with appropriate .h and .cfg files, it can now handle the tests from elliotchance/c2go.
Some thoughts on how the projects compare: Jan’s project is clearly intended for cases where the C source will always be the canonical representation of the project, since the Go code he plans to produce will be unreadable and unmaintainable. But it is the most universal. In theory at least, the approach would be able to handle any C source, no matter how obfuscated, and produce a Go package out of it. The other two projects produce Go code that, while not idiomatic, is fairly readable. One of the biggest differences is that Elliot’s runs the code through a real C preprocessor (in clang), and Russ’s doesn’t. (It supports #include, and I’ve added simple #defines for constants.) Using a real preprocessor definitely increases universality, and allows using system headers instead of the custom, stripped-down headers that Russ’s works best with. On the other hand, a preprocessed file tends to contain extra cruft. One plus for readability for Russ’s is that it preserves comments. Russ’s is, of course, the most mature, since it has been used on a large real-world codebase. Andy -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
