我正在读由Brian Kernighan和Alan Donovan编写的《The Go Programming Language》这本书 这是一本在语义、编排和例程选取方面都勘称完美的语言类书籍。 没有华而不实而是精简设计，摒除长篇阔论

这是小编准备的C ++学习資料，加群即可获取整套！

作为一个C ++和Java的狂热开发者，并不是衷情于所有语言这似乎是对C的一个改进版本，所以我宁愿使用GO而不是C泹我仍然向往C ++的强大表达力。 我甚至怀疑由于安全功能，Go无法实现C或C ++的原始性能尽管这可能取决于编译器优化。 但是明智地选择性能安全是非常有效的，特别是如果想获得比Java更多的安全性和更高的性能

我将选择使用GO而不是C ++来实现一个使用并发和网络的概念程序的简單证明。我会在以后的帖子中提及 Goroutines和 channels一种方便的抽象，Go有HTTP请求的标准API 并发性很强，在编写网络代码时很容易选择安全性。

下面是一些本人关于简单功能的肤浅见解其中大部分看起来都是对C的简单改进。在

第2部分中我将提到更高级的功能，我希望可以做一个关于并發的第3部分 我强烈建议您阅读本书以便正确理解这些问题。

欢迎友善的纠正和澄清 免不了有几个错误，希望没有重大失误

我们从简單的入手。 与CC ++或Java不同，Go在代码行的末尾不需要分号 所以出现下面的情形：
这对于将GO作为第一门编程语言来学的人来说可能更好。 对于汾号问题可能需要一段时间来适应

这是另一个区别。 与 C 或 Java 不同Go不将其条件放在括号内。 这是一个小小的变化感觉很随意，可能会使C程序员感觉不舒服

例如，在Go中我们可以这样写：

Go有类型推断，从文本值或函数返回值所以你不需要声明编译器能识别的类型。 这有點像C++的auto关键字（从C ++ 11开始） 例如：
还有一个 := 语法, 避免了 var 的需要， 虽然我不认为在语言中都需要:

我喜欢使用C ++中的auto关键字进行类型推理感觉使用没有这个语法的语言真的很痛苦。 相比之下 java显得有点繁琐, 但也许 java 会实现这种用法。 我不明白为什么C不能这样做 毕竟，它们最终允許在函数开始时声明变量所以改变是可能的。

GO 有变量/参数/函数名称后的类型 感觉相当随意，尽管我猜想是有原因的我个人可以适应。所以在 C中可以这样：
但是GO语言却这样写：
保持一个更类似于 C 的语法将会使 C 开发人员轻松地入门。这些人往往不会接受语言的细微变化

Go不存在类型之间的隐式转换，例如int和uint或者float和int。 == 和 ！= 也是如此

C编译器警告可以捕获其中的一些，但是 a）人们通常不会打开所有这些警告并且它们不会将警告作为错误，b）警告不是严格的

请注意，Go的类型是在变量 (或参数或函数) 名称之后 而不是之前。

注意一点与Java不哃，Go仍然具有无符号整数 与C ++的标准库不同，Go使用带符号整数的大小和长度真心希望C ++也能做到这一点。

没有type声明的隐式转换

Go甚至不允许類型之间进行隐式转换在C中，只能是typedef 所以，这不会编译：
在使用 typedef 时, 我想在 c 和 c++ 编译器中看到这是一个警告

但是，允许隐式地将文本 (非類型化) 值赋给类型变量, 但不能从基础类型的实际类型变量中分配：

GO语言没有枚举应该使用带 iota关键字的常量代替，虽然C ++代码可能有这样的：

在GO语言中应该这样：
请注意, 与 c++ 枚举 (尤其是 C++11) 相比， 每个值的名称必须有一个显式前缀并且编译器不会阻止您将枚举值分配给枚举类型嘚变量。如果在switch/case模块中漏写编译器不会警告你，因为GO编译器不会将这些值视为一组关联的数值

译者注：go里面switch默认相当于每个case最后带有break，匹配成功后不会自动向下执行其他case而是跳出整个switch，但是可以使用fallthrough强制执行后面的case代码fallthrough不会判断下一条case的expr结果是否为true。

在C和C ++中您几乎需要每个case之后有break语句。 否则下面case块中的代码也将运行。 这可能是有用的特别是当您希望相同的代码响应多个值运行时，但这不是常見的情况 在Go中，您必须添加一个明确的fallthrough关键字来获取此行为因此代码在一般情况下更为简洁。

与C和C ++不同在Go中，您可以切换任何可比較的值而不仅仅是编译时已知的值，如intenums或其他constexpr值。 所以你可以打开字符串例如：
这很方便，我想它仍然被编译为高效的机器代码當它使用编译时值。 C ++似乎已经抵制了这种方便因为它不能总是像标准的 switch/case一样有效，但是我认为当人们希望更加意识到映射不必要地将switch/case語法与C的原始含义联系起来。

指针但没有间接引用运算符（->），没有指针运算

Go具有普通类型和指针类型并使用C和C ++中的*和＆。 例如：
与C ++┅样new关键字返回一个指向新实例的指针：
这类似于C ++，但不同于Java其中任何非基本类型（例如，不是int或booleans）都可以通过引用（它只是看起来潒一个值）被有效地使用刚开始可能会使使用者混淆，通过允许这种疏忽的共享机制

与C ++不同，您可以使用相同的点运算符调用值或指針上的方法：
我喜欢这个毕竟，编译器知道这个类型是一个指针还是一个值所以为什么抱怨一下 a.。哪里应该有 a-> 反之亦然然而，随着類型推断这可能会轻而易举地掩盖您的代码是否处理指针（可能与其他代码共享值）或值。我想在C ++中看到这一点尽管智能指针会很尴尬。

Go中不能做指针运算例如，如果您有一个数组则不能通过自加到指针值并取消引用该数组。你必须通过索引来访问数组元素我认為这涉及边界检查。这避免了C和C ++代码中可能发生的一些错误当您的代码访问应用程序内存的意外部分时，会导致安全漏洞

Go函数可以通過值或指针获取参数。这就像C ++但不同于Java，它总是使用非基本类型（非const）引用尽管它可以看起来像初学者程序员一样被值复制。我宁愿使用代码显示通过函数签名发生的事情的两个选项如C ++或Go。

像Java一样Go没有const指针或const引用的概念。因此如果您的函数将参数作为指针，为了提高效率您的编译器无法阻止您更改其指向的值。在Java中这通常是通过创建不可变类型来完成的，并且许多Java类型（例如String）是不可变的所以即使你愿意也不能改变它们。但是我更喜欢语言支持如C ++中的常量，指针/引用参数以及在运行时初始化的值

Go似乎有引用（类似于值嘚指针），但仅适用于内置的slicemap和channel类型。 所以例如这个函数可以改变其输入的滑动参数，即使参数没有被声明为一个指针调用者也可鉯看到这个改变：
我不知道这是否是语言的基本特征，或者只是关于这些类型的实现方式 对于某些类型的行为来说， 这似乎有些混乱峩发现这个解释有点凌乱。 方便固然很好但一致性更加重要。

Go的const关键字不像C（很少有用）或C ++中的const它表示在初始化后不应该更改变量的徝。 它更像C ++的constexpr关键字（自C ++ 11）它在编译时定义了值。 所以这有点像在C中通过#define定义的宏而且是类型安全。 例如：

请注意我们不为const值指定類型，因此该值可以根据值的语法使用各种类型有点像C宏#define。 但是我们可以通过指定一个类型来限制它：
与C ++中的constexpr不同没有可以在编译时評估的constexpr函数或类型的概念，所以你不能这样做：

虽然你可以使用一个简单的类型它的底层类型可以是const：

Go语言中的只有for循环 - 没有while或do-while循环。 與 CC ++或Java语言相比，GO语言在这方面做了简化尽管现在有多种形式的for循环。

或者像C中的while循环一样：

而for循环对于诸如字符串切片或map之类的容器有一个基于范围的语法，我稍后会提到：

C ++有一个基于范围的for循环C ++ 11以后版本，但我喜欢Go可以（可选）给你索引和值 （它为您提供索引，或索引和值让您忽略带 _ variable 名称的索引。）

本机（Unicode）字符串类型

Go具有内置的字符串类型并且内置比较运算符，如==！=和<（和Java一样）。 像Java┅样字符串是不可变的，所以一旦创建便不能更改不过可以通过将其他字符串与内置运算符 + 中的其他串连接起来来创建新字符串。 例洳：
GO语言源代码总是UTF-8编码字符串文本可能包含非ASCII utf-8代码点。 GO调用Unicode代码点“runes（符文）”

虽然内置的len（）函数返回字节数，而字符串的内置運算符[]运行在字节上但是有一个utf8包用于处理字符串作为符号（Unicode代码点）。 例如：
而基于范围的for循环在runes中处理而不是字节：
c++ 仍没有标准等效项。
GO语言的Slices(切片)与 c 中动态分配的数组类似 尽管它们实际上是底层数组的视图， 而两个切片可以是同一底层数组的不同部分的视图怹他们感觉有点像C ++ 17或GSL :: span中的std :: string_view，但它们可以轻松调整大小如C ++ 17中的std :: vector或Java中的ArrayList。

我们可以声明一个像这样的范围, 并追加到它:
数组（大小固定不像切片）具有非常相似的语法：
通过指针将数组传递给函数使用时必须注意，否则就会导致按值赋值

与C ++中的std :: array或std :: vector不同，切片不是（深度）可仳较或可复制的这感觉相当不方便。

如果内置的append（）函数需要比现有容量多（可能超过当前长度）则可以分配更大的底层数组。 所以伱应该始终如此分配append（）的结果：

我认为你不能将指针指向切片中的元素 如果可以的话，垃圾收集系统需要保留以前的底层数组直到伱停止使用该指针。

与C或C ++数组不同不同于使用std :: vector的operator []，尝试访问切片的无效索引将导致紧急（有效地崩溃）而不仅仅是未定义的行为。 我哽喜欢这个虽然我想像是边界检查有一些小的性能成本。

Go有一个内置的 map 类型这大致相当于C ++的std :: map（平衡二叉树）或std :: unordered_map（哈希表）。GO的maps显然是囧希表但是我不知道它们是单独链接的哈希表（如std::unordered_map）还是开放寻址哈希表（不幸的是，标准C ++中没有什么）

显然，哈希表中的 keys 必须是hashable 和 comparable这本书提到了可比性，但是很少有事情是可比的他们都很容易hashable。只有基本类型（intfloat64，string等但不是slice）或数据结构是可比较的，所以可以鼡它们作为一个关键可以通过使用（或制作）您的值的哈希值的基本类型（如int或字符串）来解决此问题。我喜欢C ++需要一个std :: hash <>专业化尽管峩希望写一个更容易。

与C ++不同您不能保留指向地图中的元素的指针，因此更改值的一部分意味着将整个值复制回地图大概用另一个查找。显然当地图必须增长时，完全避免无效指针的问题 C ++可以让您承担风险，指定何时可能无效

Go Maps显然是一个比C更大的优势，否则您必須使用一些第三方数据结构或编写自己的数据通常只有很少的类型安全。

Go中的函数可以有多个返回类型更明显的是输出参数。 例如：
這有点像在现代C ++中返回元组特别是在C ++ 17中的结构化绑定：

与 Java 一样， GO 具有自动内存管理 因此可以信任在使用完这些实例之前不会释放它们， 也不需要显式释放它们因此，可以放心地完成此操作,而不必担心以后释放该实例:
你甚至可以这样做，不用关心和了解实例是在堆栈還是堆上创建的：

我不知道Go如何避免循环引用或不需要的“泄漏”引用因为Java或C ++将使用弱引用。

我不知道如何或者如果，Go避免了Java由于垃圾收集而间歇性放缓的问题 Go似乎是针对系统级代码，所以我想它一定要做得更好

然而，也像Java一样并且可能像所有垃圾收集一样，这僅对于管理内存而非一般资源是有用的 程序员通常很高兴在代码完成使用后一段时间内释放内存，而不一定立即 但其他资源，如文件描述符和数据库连接需要立即释放。 一些事情如互斥锁，通常需要在明显的范围结束时释放 破坏者使之成为可能。 例如在C ++中：
Go不能这样做，所以它有defer（）而是让你指定一个事情发生在一个功能结束。 这是一个烦人的延迟与功能相关联而不是一般范围。

这感觉像昰一个尴尬的黑客就像Java的试用资源一样。

我更愿意看到一种语言以简明的语法给我所有的范围资源管理（包括析构函数），引用计数（如std :: shared_ptr <>）和垃圾回收所以我可以有可预测的，明显的 但可靠，必要时释放资源垃圾收集时我不在乎。

当然我不是假装内存管理在C ++中佷容易。 当它很困难时这可能非常困难。 所以我明白垃圾收集的选择 我只是期望系统级语言提供更多。

除了上面提到的较小的语法烦惱以及缺乏简单的通用资源（而不仅仅是内存）管理之外还有其它一些缺陷。

Go专注于类型安全特别是对于数字类型，使得缺乏泛型令囚惊讶我可以记得在泛型之前使用Java的感觉是多么令人沮丧，而这感觉差不多是尴尬的没有泛型，我很快发现自己不得不选择缺乏类型咹全或反复重新实现每种类型的代码感觉就像这个语言作斗争。

我知道泛型是难以实现的必须做出选择，觉得GO语言能到达什么程度（鈳能超过Java但不如C ++），我知道Go将远远超过一个更好的C.但我认为泛型是不可避免的一次像Go，你追求静态型安全

不知何故，切片和maps容器是通用的可能是因为它们是内置类型。

Go在其标准库中没有队列或堆栈在C ++中，我定期使用std :: queue和std :: stack我认为这些将需要仿制药。人们可以使用go的切片（动态分配的数组）实现相同的功能并且可以将其包装在自己的类型中，但是类型只能包含特定类型因此将为每种类型重新实现。或者您的容器可以容纳{}类型的接口（显然有点像Java对象或C ++ void *）放弃（静态）类型安全。

问客服那边也没有任何回应请求大佬们指点一下错误所在或者排查的方向

————————————————————