在执行 3run_distrib_test_cmake.bat 时如果出现

1>E:\gRPC\mini\quote\cmake\build\quote_service.grpc.pb.h : warning C4819: 该文件包含不能在当前代码页(936)中表示的字符。请将该文件保存为 Unicode 格式以防止数据丢失

警告，后续跟着令人困惑的报错内容，且错误定位行是错乱的。手动将文件编码改为 UTF-8 BOM 就能解决此问题，but why

找错方向了，问题其实还是源于跨平台的换行符。gRPC 生成的文件格式是 Unix(LF)，大概率上在 Windows 平台也能用，但不知道为什么偏偏 quote_service.grpc.pb.h 出现了异常字符？同期一共生成了 8 个文件：

data_define.grpc.pb.cc
data_define.grpc.pb.h
data_define.pb.cc
data_define.pb.h
quote_service.grpc.pb.cc
quote_service.grpc.pb.h    # 只有这个出现异常
quote_service.pb.cc
quote_service.pb.h

只需要在 notepad++ 中将异常的 quote_service.grpc.pb.h 文件格式改为 Windows(CRLF) 后再次执行 3run_distrib_test_cmake.bat 即可正常

深切地再次体会到，要知其所以然！

cmake 的 find_package 做了什么？以下引入链接库时都引入了什么，怎么引入的？

引入的静态库都做是做什么的？grpc_unsecure.lib 怎么引入的？

# Targets greeter_[async_](client|server)
foreach(_target
  greeter_secure_server )#greeter_secure_server)
  add_executable(${_target} "${_target}.cc"
    ${hw_proto_srcs}
    ${hw_grpc_srcs})
  target_link_libraries(${_target}
    ${_GRPC_GRPCPP_UNSECURE}
    ${_PROTOBUF_LIBPROTOBUF}
    gRPC::grpc_cronet
    gRPC::grpc++
    )
endforeach()

都是 cmake 的特性，见于 #9 构建 helloworld 时

内存的分配和释放是由编译器运行时在栈上自动操作的（new/delete 对应的堆操作除外），虽然就像 new/delete，内存分配和对象构造组合在一起，对象析构和内存释放组合在一起，但“组合”也就意味着两者是独立的概念：构造函数不负责内存分配，析构函数也不负责内存释放。

当只传入一个指针类型的实参时，定位 new 表达式构造对象但是不分配内存。引用自第 729 页。

调用析构函数可以清除给定的对象但是不会释放该对象所在的空间。如果需要的话，我们可以重新使用该空间。引用自第 730 页

• 方案一：传统的 msvc 项目是在解决方案中切换编译模式的，而非不同编译模式对应不同的解决方案。
• 方案二：但项目构建工具如果定位成 cmake 的话，需要考虑的就是整合 CMakeLists.txt 以及上层 bat 脚本

在此项目从第三方拷贝过来的 xx\testinstall[d]\lib\cmake\grpc\gRPCTargets.cmake 文件中，使用了大量的绝对路径，当把外界目录清理之后，使用 .bat 执行 cmake 构建时报错！

在 client.js 弃用 combined_creds 改用 channel_creds 之后，node .\fetchStaticQuote.js 能够执行；’node .\fetchQuote.js 报错如下

PS E:\gRPC\zhao\js-demo\test\node_client> node .\fetchQuote.js
ServiceClient {
  '$interceptors': [],
  '$interceptor_providers': [],
  '$channel': Channel {} }
2018-06-26T09:26:56.031Z
2018-06-26T09:26:56.043Z
{ Error: 2 UNKNOWN: cannot find user
    at Object.exports.createStatusError (E:\gRPC\zhao\js-demo\test\node_client\node_modules\grpc\src\common.js:87:15)
    at ClientDuplexStream._emitStatusIfDone (E:\gRPC\zhao\js-demo\test\node_client\node_modules\grpc\src\client.js:235:26)
    at ClientDuplexStream._receiveStatus (E:\gRPC\zhao\js-demo\test\node_client\node_modules\grpc\src\client.js:213:8)
    at Object.onReceiveStatus (E:\gRPC\zhao\js-demo\test\node_client\node_modules\grpc\src\client_interceptors.js:1290:15)
    at InterceptingListener._callNext (E:\gRPC\zhao\js-demo\test\node_client\node_modules\grpc\src\client_interceptors.js:564:42)
    at InterceptingListener.onReceiveStatus (E:\gRPC\zhao\js-demo\test\node_client\node_modules\grpc\src\client_interceptors.js:614:8)
    at E:\gRPC\zhao\js-demo\test\node_client\node_modules\grpc\src\client_interceptors.js:1110:18
  code: 2,
  metadata: Metadata { _internal_repr: {} },
  details: 'cannot find user' }
PS E:\gRPC\zhao\js-demo\test\node_client>

在 run_distrib_test_cmake.bat 批处理文件中有以下命令：

rd  /S /Q quote\cmake\build\CMakeFiles
del /S /Q quote\cmake\build\CMakeCache.txt

无论是在 powershell 还是 cmd 中执行脚本都能够顺利执行。

可是如果在交互窗口单独输入命令，cmd.exe 可以顺利执行，powershell 报错：

Remove-Item : 找不到接受实际参数“/Q”的位置形式参数。
所在位置 行:1 字符: 1
+ rd  /S /Q quote\cmake\build\CMakeFiles
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Remove-Item]，ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand

#13

为什么让用户继承某个基类？多数是为了让用户重写某个（或某几个）虚函数，这么做的目的基本上就是为了约束用户使用指定的函数签名，而这也正是 std::function<> 和 std::bind() 的强项！

以前，函数指针无法携带状态，所以的确有使用虚函数约束用户使用特定函数签名的理由。但 modern c++ 的 std::function<> 允许使用重载了函数调用运算符的类（可调用对象），结合 std::bind() 更进一步可以使用成员函数，所以是否到了抛弃继承的时候了？

观察者模式

传统的观察者模式，限制了观察者必须从某个基类继承：

This places a restriction on the system: only types derived from Observer can be used. This introduces a tight coupling between the Subject and anything that might want to observe it. It would be nice to be able to have a more general solution, where Subject and observers know nothing of each other. 引用来源

帖子中使用 std::function<> 实现观察者模式，造成无法取消订阅！帖子末尾评论中给出了 workaround，也有同道给出了 具体实现（可惜是错的）

使用 modern c++ 实现观察者模式貌似都改用了 std::function<>（以下两篇帖子尚未细看）：

• https://codereview.stackexchange.com/questions/97360/observable-template-in-modern-c
• https://codereview.stackexchange.com/questions/92199/c-observer-design-pattern-implementation

陈硕

Scott Meyers 的 《Effective C++ 3rd ed.》 第 35 条款提到了以 boost::function 和 boost:bind 取代虚函数的做法

如果一个程序库限制其使用者必须从某个 class 派生，那么我觉得这是一个糟糕的设计。

bin/ include/
这两个目录应该是不区分 debug/release 的。但 bin/ 目录下的 *.dll 文件例外

cmake/ lib/
区分编译模式

share/
不知道这个目录什么作用

代码怎么写？

构建 grpc——Windows 平台用不到/用不起

在使用最新的 master 分支编译，发现其说明文档针对 windows 平台有了很大改进。but 仍然不能顺滑地编译并得到结果

cmake: Windows, Using Ninja

报错（未解决），找不到 C/CXX 编译器

无论是运行 vcvarsXXX.bat 还是将 cl.exe 路径加入到环境变量中，都无法使 cmake .. -GNinja -DCMAKE_BUILD_TYPE=Release 顺利运行。

在卸载 msvc2017，修复 msvc2015 编译环境后，在 “VS2015 x86 本机工具命令提示符” 中顺利编译。编译过程报错：（Debug/Release 模式都报错）（未解决）

third_party\boringssl\crypto_test_data.cc(2622): error C2001: 常量中有换行符

cmake: Windows, Using Visual Studio 2015

在同时安装 msvc2015/2017 的系统上，报错同上

-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:31 (project):
  No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:31 (project):
  No CMAKE_CXX_COMPILER could be found.

卸载 msvc2017 并修复 msvc2015 后编译、安装成功，自定义安装目录。进一步构建 helloworld

# release 成功
cmake .. -G "Visual Studio 14 2015" -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH="E:\gRPC\grpc\180622"
# debug 失败
cmake .. -G "Visual Studio 14 2015"  -DCMAKE_PREFIX_PATH="E:\gRPC\grpc\180622d"

debug 模式会报错（未解决）

E:\gRPC\grpc\msvc15\third_party\boringssl\crypto_test_data.cc(2622): error C2001: 常量中有换行符

cmake: Windows, Using Visual Studio 2017

报错（未解决）

error C2220: 警告被视为错误 - 没有生成“object”文件

warning C5045: 如果指定了 /Qspectre 开关，编译器会插入内存负载的 Spectre 缓解

C5045 是 msvc2017 新增内容，参考 Workaround for Spectre warning MSVC C5040

https://blog.csdn.net/solstice/article/details/5238671

以下操作，除非明确说明，否则使用的都是我自己生成的证书，而非赵哥给的 yuanda 包！

• 操作系统 win10
• 编译环境 msvc2015
• grpc 提交 id:9a95b41e5d70bd0a9ef9ba6069532981dfb675d9

首先我们认为（不一定就是对的）

# Targets greeter_[async_](client|server)
foreach(_target
  greeter_secure_client greeter_secure_server)
  add_executable(${_target} "${_target}.cc"
    ${hw_proto_srcs}
    ${hw_grpc_srcs})
  target_link_libraries(${_target}
    ${_GRPC_GRPCPP_UNSECURE}
    ${_PROTOBUF_LIBPROTOBUF}
    )
endforeach()

结合

// server
builder.AddListeningPort(server_address, grpc::InsecureServerCredentials());

// client
stub_ = Greeter::NewStub(grpc::CreateChannel(server, grpc::InsecureChannelCredentials()));

生成的一定是 Insecure 的客户端、服务端。试验表明两者能够互通。

我们记为 real_insecure_server.exe real_insecure_client.exe

Protoc treats \r as plain whitespace, so it should have no problem with Windows line endings. I just tested this and sure enough, protoc works fine with .proto files that use Windows-style line endings.

来源：https://groups.google.com/forum/#!topic/protobuf/jB8o-sGwpRw