这是我参与8月更文挑战的第5天，活动详情查看：8月更文挑战

系列文章见：

CGO是什么

简单点来讲，如果要调用C++，C写的库（动态库，静态库），那么就需要使用Cgo。其他情况下一般用不到，只需要知道Go能调用C就行了，当然C也可以回调到Go中。

使用Cgo有2种姿势：

  1. 直接在go中写c代码
  2. go调用so动态库（c++要用extern “c”导出）

为了熟悉CGO，我们先介绍第一种方法，直接在Go中写C代码。

入门，直接在Go中写C代码

首先，通过import “C”导入伪包（这个包并不真实存在，也不会被Go的compile组件见到，它会在编译前被CGO工具捕捉到，并做一些代码的改写和桩文件的生成）

　　

然后，Go 就可以使用C的变量和函数了， C.size_t 之类的类型、诸如 C.stdout 之类的变量或诸如 C.putchar 之类的函数。

　　

如果“C”的导入紧跟在注释之前，则该注释称为序言。例如：

　　

序言可以包含任何 C 代码，包括函数和变量声明和定义。然后可以从 Go 代码中引用它们，就好像它们是在包“C”中定义的一样。可以使用序言中声明的所有名称，即使它们以小写字母开头。例外：序言中的静态变量不能从 Go 代码中引用；静态函数是允许的。

所以，你可以直接在/**/里面写C代码（注意，C++不行！）：

　

编译下，会出现下面的问题（ fmt.Println(C.add(1, 2)) 能编译通过，思考下为什么？ ）：

　　

为什么呢？因为C没有办法使用Go的类型，必须先转换成CGO类型才可以，改成这样就行了：

　　

运行后输出：

　　

CGO基础类型

就像上面的代码一样，Go没有办法直接使用C的东西，必须先转换成CGO类型，下面是一个基础类型对应表。

C类型CGO类型GO类型
char C.char byte
signed char C.schar int8
unsigned char C.uchar uint8
short C.short int16
unsigned short C.ushort uint16
int C.int int32
unsigned int C.uint uint32
long C.long int32
unsigned long C.ulong uint32
long long int C.longlong int64
unsigned long long int C.ulonglong uint64
float C.float float32
double C.double float64
size_t C.size_t uint 
#include 
C类型CGO类型GO类型
int8_t C.int8_t int8
int16_t C.int16_t int16
uint32_t C.uint32_t uint32
uint64_t C.uint64_t uint64

字符串、数组和函数调用

那么，在Go要如何传递字符串、字节数组以及指针？ CGO的C虚拟包提供了以下一组函数，用于Go语言和C语言之间数组和字符串的双向转换：

　

字符串，可以通过C.CString()函数（别忘记通过free释放）：

　

字节数组，直接使用go的数组，然后强制转换即可：

 

对应类型的指针，直接使用Cgo类型，然后&取地址即可：

　　

假如ocr识别函数如下：

　　

有3个参数：

  • image_path：指示了要识别的图片路径。
  • out_buffer：识别到的文字输出到这里，是一个char字节数组。
  • len：指示输出字节缓冲区大小，调用成功后，值变成字符串长度，便于外界读取。

在go中调用方式如下:

　

分离Go和C代码

为了简化代码，我们可以把C的代码放到xxx.h和xxx.c中实现。

有以下结构：

　　

hello.h的内容：

　　

hello.c：

　　

main.go中调用hello.h中的函数：

　　

常用cgo编译指令

如果我们把h和c文件放到其他目录，则编译会报错:

　　

这里应该可以使用#cgo预编译解决（CFLAGS、CPPFLAGS、CXXFLAGS、FFLAGS和LDFLAGS） ：

  • CFLAGS：-D部分定义了宏PNG_DEBUG，值为1。-I定义了头文件包含的检索目录
  • LDFLAGS：-L指定了链接时库文件检索目录，-l指定了链接时需要链接png库

通常实际的工作中遇到要使用cgo的场景，都是调用动态库的方式，所以这里没有继续往下深究上面的错误如何解决了。

调用C静态库和动态库

目录结构如下：

1）静态库

把上面的hello.h 和 hello.c 生成为静态库（需要安装gcc，省略）：

　　

Go中调用C静态库：

　　

2）动态库

生成

　　

调用代码和上面一样的，LDFLAGS加上-lstdc++：

注意，生成的so文件一定的是libhello.so，然后在Go中只需要写-lhello即可，不是libhello，linux下会自动增加lib前缀。

唯一不同的是，静态库需要指定so文件的搜索路径或者把so动态库拷贝到/usr/lib下，在环境变量中配置：

　　

更多关于静态库和动态库的区别：segmentfault.com/a/119000002…

调用C++动态库

本质上和调用c动态库在Go的写法上是一样的，只是需要导出成C风格的即可：

CGO的缺陷

cgo is not Go中总结了cgo 的缺点：

  1. 编译变慢，实际会使用 c 语言编译工具，还要处理 c 语言的跨平台问题
  2. 编译变得复杂
  3. 不支持交叉编译
  4. 其他很多 go 语言的工具不能使用
  5. C 与 Go 语言之间的的互相调用繁琐，是会有性能开销的
  6. C 语言是主导，这时候 go 变得不重要，其实和你用 python 调用 c 一样
  7. 部署复杂，不再只是一个简单的二进制

这篇文章描述了CGO通过go去调用C性能开销大的原因：blog.csdn.net/u010853261/…

  • 必须切换go的协程栈到系统线程的主栈去执行C函数
  • 涉及到系统调用以及协程的调度。
  • 由于需要同时保留C/C++的运行时，CGO需要在两个运行时和两个ABI（抽象二进制接口）之间做翻译和协调。这就带来了很大的开销。

《GO原本》中进一步通过runtime源码解读了原因

使用的时候，自己灵活根据场景取舍吧

CGO最佳使用场景总结

CGO的一些缺点：

  1. 内存隔离 

  2. C函数执行切换到g0(系统线程) 

  3. 收到GOMAXPROC线程限制 

  4. CGO空调用的性能损耗(50+ns) 

  5. 编译损耗(CGO其实是有个中间层)

CGO 适合的场景：

  1. C 函数是个大计算任务(不在乎CGO调用性能损耗) 

  2. C 函数调用不频繁

  3. C 函数中不存在阻塞IO 

  4. C 函数中不存在新建线程(与go里面协程调度由潜在可能互相影响) 

  5. 不在乎编译以及部署的复杂性

更多可以阅读：

Ocr实战

1.chineseocr_lite介绍

Star: 7.1 K

介绍：超轻量级中文ocr，支持竖排文字识别, 支持ncnn、mnn、tnn推理 ( dbnet(1.8M) + crnn(2.5M) + anglenet(378KB)) 总模型仅4.7M。

 

这个开源项目提供了C++、JVM、Android、.Net等实现，没有任何三方依赖，经作者实践，识别效果中等，越小的图片越快。

比如识别一个发票号码，只需要50ms左右：

rpa1.png

复杂的图片识别大概500-900ms左右：

fapiao.jpg-result.jpg

表格识别效果一般

baojia1.png-result.jpg

比如发票的某个位置，身份证，银行卡等等

2.编译chineseocr_lite

按照 chineseocr_lite/cpp_projects/OcrLiteOnnx 中的README.md文档编译即可，推荐在Linux下，我再windows和Macos没编译通过。

然后需要改造成动态库，我改动的内容有：

  • 默认生成动态库，给ocr_http_server使用
  • 去掉jni的支持
  • 增加ocr.h，导出c风格函数

3.导出c函数

ocr.h

　　

ocr.cpp

　　

ocr_wrapper.go

　　

3.环境变量设置

路径包含库所在目录，或者直接把动态库拷贝到/usr/lib中，推荐后者：

　　

4.运行

效果如下

ocr.png

参考