Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

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 ?


migration rejected from May 14 at 22:45

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by Ixrec, Snowman, Matthew Flynn, Adam Zuckerman, TZHX May 14 at 22:45

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

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.

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

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.


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

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 (the association bonus does not count).

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.