最簡單的CGO程序

//cgo.go
package main

import "C"

func main(){
?? ?println("hello cgo")
}

上述代碼是一個完整的CGO程序，通過import "C"語句啟動了CGO特性，go build命令會在編譯和鏈接階段啟動gcc編譯器

源碼方式調用C函數

cgoTest.h

void SayHello(const char* s);

cgoTest.c

#include <stdio.h>
#include "cgoTest.h"

void SayHello(const char* s) {
? ? puts(s);
}

main.go

package main

/*
#include <cgoTest.h>
?*/
import "C"

func main(){
?? ?C.SayHello(C.CString("Hello world\n"))
}

上述.c文件也可以是.cpp文件，前提是編譯時需要g++

cgoTest.cpp

#include <iostream>

extern "C" {
? ? #include "cgo01.h"
}

void SayHello(const char* s) {
? ? std::cout << s;
}

上述.c和.cpp的不同實現都實現了SayHello函數，說明解放了函數的實現者，那如果是這種情況，可不可以使用go實現SayHello函數呢？

答案是可以的，這種技術也稱為面向C語言接口(.h中的接口聲明)的編程技術，該技術不僅僅可以解放函數的實現者，同時也可以簡化函數的使用者。

cgoTest.go

package main

import "C"

import "fmt"

//export SayHello
func SayHello(s *C.char){
?? ?fmt.Print(C.GoString(s)) ?//注意：這里是C.GoString
}

注意：上述main.go文件在使用C函數CString后在程序退出前沒有釋放C.CString創建的字符串會導致內存泄漏，但是對于這個小程序來說，這樣是沒有問題的，因為程序推出后操作系統會自動回收程序的所有資源

改進后的main.go代碼

package main

/*
#include <cgoTest.h>
#include <stdlib.h>
?*/
import "C"
import "unsafe"

func main(){
?? ?cs := C.CString("CPP Hello world\n")
?? ?C.SayHello(cs)
?? ?C.free(unsafe.Pointer(cs))
}

當然也有其他方法可以避免這種麻煩的情況出現，而且只需要一個go文件就可以實現面向C語言的編程

main.go (只有這一個文件)

//+build go1.10
package main

//void SayHello(_GoString_ s); //Go1.10中CGO新增的預定義C語言類型，用來表示Go語言字符串
import "C"
import "fmt"

//export SayHello
func SayHello(s string){ //注意這里變量類型為Go 中的string
?? ?fmt.Print(s)
}
func main(){
?? ?C.SayHello("Hello CGO\n")
}

上面代碼執行時先從Go語言的main函數開始，到CGO自動生成的C語言版本SayHello橋接函數，最后到Go語言環境的SayHello函數，是不是有一種合久必分、分久必合的感覺，這也是CGO編程的精華所在。

內部機制

如果在一個go文件中出現了import "C" 指令則表示將調用cgo命令生成的對應的中間文件，下圖是cgo生成的中間文件的示意圖：

在保證go build 沒問題的情況下執行如下命令就可以生成中間文件

go tool cgo main.go

生成的中間文件在_obj目錄下

為了在C語言中使用Go語言定義的函數，我們需要將Go代碼編譯為一個C靜態庫

go build -buildmode=c-archive -o SayHello.a  cgoTest.go

如果沒有錯誤的話，會生成一個SayHello.a靜態庫和SayHello.h頭文件

既然提到了靜態庫的生成，順便也說一下Go生成C動態庫

go build -buildmode=c-shared -o SayHello.so cgoTest.go

編譯和鏈接參數

編譯和鏈接參數是每一個C/C++程序員需要經常面對的問題。構建每一個C/C++應用均需要經過編譯和鏈接兩個步驟，CGO也是如此

編譯參數：CFLAGS/CPPFLAGS/CXXFLAGS

編譯參數主要是頭文件的檢索路徑，預定義的宏等參數。理論上來說C和C++是完全獨立的兩個編程語言，它們可以有著自己獨立的編譯參數。 但是因為C++語言對C語言做了深度兼容，甚至可以將C++理解為C語言的超集，因此C和C++語言之間又會共享很多編譯參數。 因此CGO提供了CFLAGS/CPPFLAGS/CXXFLAGS三種參數，其中CFLAGS對應C語言編譯參數(以.c后綴名)、 CPPFLAGS對應C/C++ 代碼編譯參數(.c,.cc,.cpp,.cxx)、CXXFLAGS對應純C++編譯參數(.cc,.cpp,*.cxx)

鏈接參數：LDFLAGS

鏈接參數主要包含要鏈接庫的檢索目錄和要鏈接庫的名字。因為歷史遺留問題，鏈接庫不支持相對路徑，我們必須為鏈接庫指定絕對路徑。 cgo 中的 ${SRCDIR} 為當前目錄的絕對路徑。經過編譯后的C和C++目標文件格式是一樣的，因此LDFLAGS對應C/C++共同的鏈接參數

CGO在使用C/C++資源的時候一般有三種形式：直接使用源碼；鏈接靜態庫；鏈接動態庫。直接使用源碼就是在import "C"之前的注釋部分包含C代碼，或者在當前包中包含C/C++源文件。鏈接靜態庫和動態庫的方式比較類似，都是通過在LDFLAGS選項指定要鏈接的庫方式鏈接

通過靜態庫的方式調用C函數

如果CGO中引入的C/C++資源有代碼而且代碼規模也比較小，直接使用源碼是最理想的方式，但很多時候我們并沒有源代碼，或者從C/C++源代碼開始構建的過程異常復雜，這種時候使用C靜態庫也是一個不錯的選擇。靜態庫因為是靜態鏈接，最終的目標程序并不會產生額外的運行時依賴，也不會出現動態庫特有的跨運行時資源管理的錯誤。不過靜態庫對鏈接階段會有一定要求：靜態庫一般包含了全部的代碼，里面會有大量的符號，如果不同靜態庫之間出現了符號沖突則會導致鏈接的失敗

假設dirname 下有filename.c文件和filename.h文件，則生成靜態庫的命令為

$ cd ./dirname
$ gcc -c -o filename.o filename.c
$ ar rcs libfilename.a filename.o

使用靜態庫中的C函數

package main

//#cgo CFLAGS: -I./dirname
//#cgo LDFLAGS: -L${SRCDIR}/dirname -lfilename
//
//#include "filename.h"
import "C"
import "fmt"

func main() {
? ? fmt.Println(C.filename_func())
}

通過動態庫的方式調用C函數

動態庫出現的初衷是對于相同的庫，多個進程可以共享同一個，以節省內存和磁盤資源。但是在磁盤和內存已經白菜價的今天，這兩個作用已經顯得微不足道了，那么除此之外動態庫還有哪些存在的價值呢？從庫開發角度來說，動態庫可以隔離不同動態庫之間的關系，減少鏈接時出現符號沖突的風險。而且對于windows等平臺，動態庫是跨越VC和GCC不同編譯器平臺的唯一的可行方式

動態庫的生成

gcc -shared -o libfinename.so filename.c

對于CGO 來說，使用動態庫和靜態庫是一樣的

package main

//#cgo CFLAGS: -I./dirname
//#cgo LDFLAGS: -L${SRCDIR}/dirname -lfilename
//
//#include "filename.h"
import "C"
import "fmt"

func main() {
? ? fmt.Println(C.filename_func())
}