go get github.com/raff/walkngo
If you use --lang=c it will actually generate c++ code.
It's not perfect but it does the bulk of the conversion. Unfortunately working
with only the ast has it's limits (and I wrote this before the ssa stuff was
available)
-- Raffaele
> On Mar 24, 2017, at 6:22 PM, Brad <bradgar...@gmail.com> wrote:
>
> Interested in any feedback about the idea of making a Go -> C++ transpiler.
> Here's the rationale:
>
> * Go as a language has lots of awesome things that make it highly productive.
> Lots of Gophers would love to use Go for more projects but some common
> issues include:
> * Trying to convince your team or management to adopt Go over a "more
> traditional" language can be a tough sell: Your PHB is likely to tell you
> it's not worth the risk, because the next developer he hires may not like Go
> and he'll be screwed, whereas he knows he can find someone who will write C++
> or Java.
> * And there is also the issue of the environments in which Go will run. On
> embedded platforms (e.g. Parallax Propeller, Arduino) you can write C++, but
> you're not going to get a Go compiler for it.
> * There's also the fact in a scenario where Go co-exists with C or C++, Go
> has to have the main function and has to build the executable. Unless you
> build a shared library, you can't just start implementing parts of your
> project in Go and gradually phase things over.
>
> It's also worth noting that some of these scenarios just will never support
> all the features of the Go language, and so full support will not happen.
> You probably won't get goroutines on an Arduino, for example. But, that
> doesn't mean it wouldn't be useful to be able to write Go code in these cases
> that doesn't use that feature and is otherwise 100% correct Go.
>
> So, what if the following existed:
>
> * Tool that converts Go to C++:
> * Comments and formatting are preserved - the resulting C++ is readable. You
> can tell your boss "there's no loss here - if this doesn't work, we'll throw
> away the Go code and keep working on the C++", even though you know you will
> burn in hell for doing that ;)
> * Language constructs which have an obvious simple mapping are just directly
> converted (byte -> uint8_t, structs are structs, etc.)
> * Things that can be done with C++ code but are just ugly (e.g. defer,
> implemented with goto) would be done like that - the transpiler would just
> emit that code.
> * Features that are syntactic sugar around runtime implementations are emits
> as calls to a stripped down version of the runtime that just does the bare
> minimum to support what's needed: e.g. maps and slices are implemented with a
> C++ template - the template is the same one that is just dropped in the
> output as "map.h" and the transpiler emits code that uses it.
> * Heap allocations are mapped to a GC lib implemented in C++ - same as maps
> above, just more complicated. Same with channels.
> * Reflection could be done by emitting a bunch of type info and making all
> that work, but probably wouldn't get around to doing this in a first version.
> * "go" gets mapped to pthread_create(), cognew() or whatever.
> * As much as possible this things are kept as some sort of simple template of
> the corresponding C++ code to output, so you can easily adjust how
> allocations or "go" or whatever are emitted for a particular environment.
> * The standard library would probably need to be forked, the things that are
> heavily intertwined with the Go runtime ("runtime", "reflection", etc.) would
> probably just not be available initially, and the ones that can be patched
> and transpiled would be, and then some would probably just need a separate
> implementation in C++ (e.g. "sync"). There would be an obvious way to do
> this and it would be a normal thing in this scenario to say: "let's drop in
> an implementation of fmt that supports only the barebones formatting for use
> on embedded systems", etc.
> * Features/packages that are not supported would result in a transpiler
> error. I.e. some things "you just can't do" with this tool and that's okay.
>
> Assuming this actually worked, it might considerably lower the bar for
> adopting Go, and allow it to be used to develop in environments where we're
> not likely to see a port of the compiler any time soon. (Or where it's
> literally impossible because there are things in the language that the
> platform just can't do.)
>
> I could potentially devote some time to building this out, but I wanted to
> see if anyone had feedback on the concept. I realize it's not a simple
> project, but with the above setup it could be implemented incrementally.
> --
> 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.
--
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.
