CGO and Go languages are different.

This is a creation in Article, where the information may have evolved or changed.

CGO not go     Borrow a word from jwz Some people, when they face a problem, think "I know, I will use CGO". So now, they have two questions. I am very worried about the recent use of CGO on Gopher's Slack Channel, especially if there is an organization that intends to use a project to show Go, which is a bad idea. I have said many times about this, so maybe you hated my lobbying, so I thought about writing it down and doing it.     CGO is an amazing technology that allows Go programs to interoperate with C's class libraries. It is an extremely useful feature, and today it achieves a position that Go cannot reach. CGO is the key to getting the Go app running on Android and IOS.     However, this is only my personal opinion, I do not speak for anyone, I think CGO is overused in the Go project. I believe that when faced with the need to reload a large section of the C code written with go, programmers would prefer to use CGO to package libraries rather than go, because they think it is easier to solve the problem. I think that's a fake economy.     Obviously, there are some unavoidable problems with CGO, and the most obvious problem is that as a binary blog, you have to interact with the graphics driver or window system. However, the use of CGO problems, after the trade-offs, most people think it is still relatively small.     When you build a CGO library on a Go project, You may not realize that this tradeoff is not complete.

translated 4 months ago 2 Human top top   good translation!

build Variable length When you reference the import "C" in the package, go build will do a lot of extra work to build your code, Construction is not just to go tool compile passes a bunch of. Go files, instead: The CGO tool is called to generate various files between C conversion go and go conversion c. Your system's C compiler will be called to process all the C files in your package. All independent compilation units are grouped into an. o file.   the generated. o file is checked for a reference to it in the connector of the system. When you are programming for this package, all of the above work will be done during your compilation or testing. The Go tool handles these tasks in parallel, where possible, but the compilation time of this package increases with all C code constructs. You can refactor this part of the C code out of this package, but if you don't have to CGO, you'll naturally not have this problem. Yes, you must also debug C code compatibility issues on different platforms.

Drkaka translated 4 months ago 0 Human Top top   Good translation!

Complex constructs One of the goals of Go is to produce a language, which is the process of describing itself; Your program's resources contain enough information to use a tool to create the project. This is not to say that using Makefile to automate building projects is bad, but before CGO is introduced, you create and test nothing, except the Go tool. Later CGO was introduced, setting all the environment variables, keeping track of the shared objects and header files that might be installed in strange places, which you need to do now. Remember, go supports those platforms that don't load out-of-the-box, so you have to spend some time proposing a solution for Windows users. Also, your users will now install the C compiler instead of just installing the go compiler. They also need to install the C library on which your project depends, so you also have to bear the cost of these support.

translated 4 months ago 1 people top top   Good translation!

cross-compilation Go support for cross-compilation is the best. Depending on Go1.5 cross-compiling, you can install the program from any supported platform to any other platform via the official license on the Go Project website. Cgo is not allowed to cross-compile by default. Usually this does not pose a problem if your project is pure go. When you mix the dependencies of C libraries, you either have to give up cross-compiling your product, or you have to spend time looking for and maintaining C's cross-compiler toolchain to achieve your goals. Maybe the product you're doing is communicating with the client through TCP only, and you're planning to run it on a model of SaaS (software services  software as a service), then you don't really care about cross-compiling. However, if you are doing a product that other people will use, it may be integrated into their product, perhaps it is a monitoring solution, perhaps it is a client of your SaaS service, then you will be able to easily cross-compile the features to lock the dead. The platforms supported by the Go continue to grow. Go 1.5 adds support for 64-bit arm and PowerPC. Go 1.6 adds support for 64-bit MIPS, while IBM's s390 architecture is in Go 1.7. Available in Risc-v. If your product relies on C libraries, not only do you have to face all of the cross-compilation issues described above, you also have to make sure that the C code you rely on runs reliably on the new platform supported by Go-you have to do these limited debugs using C/go hybrid. This leads to the following question.

translated 4 months ago 1 Human top top   good translation!

You lost the entrance to all your tools. Go has some great tools, such as race analysis, performance analysis, coverage, fuzzy testing, and other source code analysis tools. None of these barriers can span cgo blood or cgo the brain. Conversely, good tools like valgrind do not understand the calling convention and stack layout of go. At this point, the work of Ian Lance Taylor, which combines C's memory cleanup and null pointer debugging in Go 1.6, will be very useful for CGO users. Combing go code and C code results to two world intersections, not alliances; C Memory Security, go program debugging. Performance is always a problem C Code and go code live in two different universes, cgo the dividing line between the two of them. The transition is not free, it depends on where it is in your code, and the cost may be insignificant or huge.

Dry all day Translated 4 months ago 1 Person top top translation of good Oh!

Other translation versions (1)

Loading ...

C does not understand the call contract or stack of go, so the go language calls to C code must first record all the details of the GO function entrance stack, and then switch to the C stack, run C code, this part of C code does not know how it was called, much less know the external Go language runtime environment. To be fair, Go also doesn't know anything about C. That's why the rules for passing data between Go and C are becoming more complex as the compiler and the garbage collector evolve to locate useless stack frames and heaps. If an error occurs during C, go can at least print the error stack information and exit the program instead of exposing the core file. It's really not easy to manage this stack of mutual calls, plus the signals, threads, and callbacks. Ian Lance Taylor has done a lot of work in the 1.6 version of the Go language to improve interoperability with C-language signal processing. This is to say that the C and Go language between the call is more cumbersome, and will always have performance overhead.

Snow falls without trace xdj Translated 4 months ago 0 Person Top top translation of good Oh!

Other translation versions (1)

Loading ...

c Yes Dominate, not your code It doesn't matter if you bundle or wrap C code in that language, Python, a jni java, some libffi language, or a CGO go; this is the world of C, you just live on it. The Go code and the C code must be consistent in how the resources are shared, such as address space, signal processing, and thread scheduling--and what I say is consistent is the assumption that go revolves around c. The  C code can assume that it has been running on a thread, or that it is running in an environment with many threads without worrying about any preparation work. You are not writing a go program using some of the logic in C libraries, instead you are writing a go program that must coexist with a conflict-prone, hard-to-replace C code that is difficult to negotiate without worrying about your problems.

translated 4 months ago 1 Human top top   good translation!

deployment Become more complex For the general reader, any description of go should contain at least one of the following words: simple, static binary This is the magic of Go, it leads the go Become a typical representative of virtual machines and run management. With CGO, you'll have to give up these. Depending on your environment, make your go project into a deb or RPM package, and assume that your other dependencies are packaged, add them to the installation dependency, and then throw the problem out of the operating system's package management, which may be possible. But the important changes to these build and deploy programs are just as hasty and straightforward as go build && SCP. It is possible to compile a completely static go program, but if your project contains CGO it will never be easy, and the consequences will affect the lifecycle of an entire build and deployment. Please choose wisely To be clear, I'm not saying you shouldn't use CGO. But before you make the deal, think carefully about the pros of go that you're giving up at the same time. Go 1.1 cross-compilation introduction Go 1.5 cross-compilation Cross-compilation becomes more complete in Go 1.5 Introduction to cross-compiling of Go

translated 4 months ago 1 Human top top   good translation!

All translations in this article are for learning and communication purposes only, please be sure to indicate the translator, source, and link to this article.
Our translation work in accordance with the CC agreement, if our work has violated your rights and interests, please contact us promptly