Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it possible to replace C and C++ with Go + cgo and interface frameworks such as Qt or DirectX with Go?

Any potential pitfalls I should be aware of?


I see that my question was not precise enough. Of course I expected problems with Go concepts that aren't available in C/C++ e.g. goroutines. What I really wanted to know was if you could use Go to replace standard C++ functionality. I hope I can convey my idea: I thought of Go as a "scripting language" to leverage C/C++ libraries with a new language.

I'd like to know:

  • Can you register Go methods as C/C++ callbacks ?
  • Can I supply Go variables as parameters to C/C++ functions ?
  • Are their pointers compatible ? Go runs on a native Vm, so I guessed there might be an abstraction layer over the memory that invalidates C/C++ pointers

Have you ever used cgo or know about its abilities ?

share|improve this question

migrated from Jan 8 '12 at 12:42

This question came from our site for professional and enthusiast programmers.

I think Go developers certainly intend the answer to this question to be yes. Go seems to me like good competition to C/C++, addressing issues no other language addresses (AFAIK). Are we there yet? Will we? I don't know. – ugoren Jan 8 '12 at 12:18
Binding to C in Go is nearly as transparent as C++, except for macros and unions. If your application makes heavy use of those, consider writing wrappers in C for those. – Vortico Aug 10 '14 at 10:57
up vote 11 down vote accepted

Go has a simple interface to C libraries: cgo. It has no support for C++ (classes, name mangling). An alternative to cgo is Swig.

Can you register Go methods as C/C++ callbacks ?

It is possible to call Go functions (not methods) from C. A simple example can be found here.

It is hard to understand what the limitations of calling C from Go are.

Cgo has currently no support for generating standalone Go libraries (.a or .so) for use from C code. Go programs are able to use C libraries, but C programs are unable to use Go libraries.

Can I supply Go variables as parameters to C/C++ functions ?

Yes. The ability to pass Go values to C (cgo) is restricted by the Go type system. For example, the C type int is accessible from Go as, so the programmer has to use an explicit type conversion even when passing integers (this verbosity is intentional).

Go source codes interfacing to C also make use of the unsafe types uintptr and unsafe.Pointer.

Are their pointers compatible ? Go runs on a native Vm, so I guessed there might be an abstraction layer over the memory that invalidates C/C++ pointers

Pointers are compatible.

share|improve this answer
Just as a point of clarification Go does not run on a VM. The compiler generates machine code not vm bytecode. – Jeremy Wall Mar 19 '12 at 2:49

Not directly, You will have to port (read as rewrite) your C or C++ code because Go is not source-level compatible with C. If you want a modern language which is source-level compatible with C (well, almost), try the D programming language. Both Go and D are not source-level compatible with C++. I do not know about Go, but D has a limited "understanding" of C++ through the extern(C++).

share|improve this answer
Who said anything about source-level compability? For that matter, who said there's an existing C or C++ project that the Go code needs to blend with? – delnan Jan 8 '12 at 13:08
@delnan: I answered to my best abilities, and to my best understanding of the question. The question is not concise, so my answer cannot be to everyone's liking. If you do not think it is good, down-vote it, if you have no constructive thing to say - please do not comment at all then. – DejanLekic Jan 8 '12 at 13:15
No need to feel offended. Your answer assumes a few things I can't find in the question (and yes, that's because the question gives very little information), so I'm asking where you got those assumptions from. Are you saying it doesn't matter whether answers build on valid assumptions or on wrong assumptions? Or that the validity of such assumptions shouldn't be discussed at all? – delnan Jan 8 '12 at 13:19
I do not know about you, but one way of understanding the "replace C and C++ with Go + cgo" may be "I want to use the same source, but different compiler (in this case Go)". I will not post any further comments as I find this discussion pointless. – DejanLekic Jan 8 '12 at 14:25
"Same source but different compiler"? I don't know when I said that. I'd be surprised if C compiles as Go. Still you got a point as my question's not very clear. It was moved and I didn't write this one myself. I've updated it to be -hopefully- more precise – lhk Jan 8 '12 at 14:57

No I don't believe so. In particular, C/C++ compatibility is hampered by:

  • Lack of a mature frontend to a well supported mainstream compiler such as GCC or LLVM.
  • Impedance mismatch between threads and goroutines. More specifically, foreign threads cannot call into the Go machinery and vice versa. Many C/C++ libraries make use of threads and callbacks in their interfaces.
  • Inability to call functions that block on I/O or system resources. This limits what libraries and functions you can call from goroutines without endangering the Go scheduler.
share|improve this answer
What's wrong with an M:N implementation of goroutines? What does "well-supported frontend" means? and how are calls to blocking functions hindered? (my copy of gc might have been affected by cosmic rays during compilation, because it does block correctly...). – Ismael Luceno Jan 8 '12 at 14:26
Recent GCC (i.e. 4.6 or 4.7) have a Go front-end. – Basile Starynkevitch Jan 8 '12 at 17:48
@BasileStarynkevitch: This is why I avoided giving details initially. Gccgo is far from ready and lags the mainline significantly. – Matt Joiner Jan 9 '12 at 1:26

It is possible, indeed. There are some bindings already done (wxWidgets, FLTK and GTK).

Please note that to link code with the original compiler, it must use the same format and calling conventions, so it's quite useless.

Gccgo on the other hand is standard and can interact in any desired way (but requires some care). It can also create shared libraries.

Take a look at the documentation.

share|improve this answer

As a concrete answer for interfacing with DirectX from Go, I have created a Direct3D9 wrapper:

and a DirectInput8 wrapper:

As for your questions, these wrappers do what you asked about, they implement callbacks, e.g. for DirectInput's device enumeration, they pass Go values and void* pointers (as unsafe.Pointer) to C and retrieve data from C.

share|improve this answer

protected by gnat May 1 at 7:26

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.