在抽象中，代码生成器为 c++ 自己的代码生成技术生成类型而不是仅仅生成所需的代码是很奇怪的。为什么 GRPC 会这样做？为什么不进一步参数化 grpc 代码生成器 (protoc + grpc_cpp_plugin) 以生成所需的入口点？
我主要想知道是否更有经验的 grpc 用户发现了这种代码生成开始的好处，或者这只是 grpc 实现中的一个错误。
【问题讨论】：
标签： c++ protocol-buffers grpc
查看生成的文件，例如here，我没有看到很多模板定义正在生成。取而代之的是许多模板实例化，一些 C++ 标准类型，如 std::unique_ptr，以及一些 GRPC 自己的类型。但类型本身并不是生成代码的一部分。
没有直接的方法可以从 C++ 代码中删除模板实例化，而且这样做也没有任何意义。如果std::unique_ptr<::grpc::ClientReader<::Namespace::GeneratedMessage>> 需要通过别名或子类实例化std::unique_ptr，或者与任何期望std::unique_ptr 的代码不兼容，则无论您要写什么。
至于少数模板定义，与WithAsyncMethod有关。这种机制似乎使用 C++ 模板自动生成服务的异步和同步定义。另一种方法是为这两种情况复制生成的代码，或者在每次调用中使用单独的if 来减慢执行速度。
一般来说，模板是 C++ 不可或缺的一部分，因此看到生成的代码使用它们也就不足为奇了。
【讨论】：