diff options
| author |  Vijay Pai <vpai@google.com> | 2017-10-09 10:15:37 -0700 |
|---|---|---|
| committer | Vijay Pai <vpai@google.com> | 2017-10-09 12:47:20 -0700 |
| commit | d137066be8c9527b5cea36132915619cc61cfc6d (patch) | |
| tree | 6eb38e5e09ca642a2d59e5ae74355828a190ed56 /doc/core | |
| parent | cd42eb0a8ea21e3002f4377b24d5f54ae7791833 (diff) | |
Add some details
Diffstat (limited to 'doc/core')
| -rw-r--r-- | doc/core/moving-to-c++.md | 24 |
1 files changed, 15 insertions, 9 deletions
diff --git a/doc/core/moving-to-c++.md b/doc/core/moving-to-c++.md index 33c3cfa0e6..4c745b38a9 100644 --- a/doc/core/moving-to-c++.md +++ b/doc/core/moving-to-c++.md @@ -6,14 +6,17 @@ ctiller, markdroth, vjpai ## Background and Goal -gRPC core was originally written in C89 for several reasons (possibility of -kernel integration, ease of wrapping, compiler support, etc). Over time, this -was changed to C99 as all relevant compilers in active use came to support C99 -effectively. Now, gRPC core is C++ (although the code is still idiomatically C -code) with C linkage for public functions. Throughout all of these transitions, -the public header files are committed to remain in C89. - -The goal now is to make gRPC core true idiomatic C++ compatible with +gRPC core was originally written in C89 for several reasons +(possibility of kernel integration, ease of wrapping, compiler +support, etc). Over time, this was changed to C99 as all relevant +compilers in active use came to support C99 effectively. +[Now, gRPC core is C++](https://github.com/grpc/proposal/blob/master/L6-allow-c%2B%2B-in-grpc-core.md) +(although the code is still idiomatically C code) with C linkage for +public functions. Throughout all of these transitions, the public +header files are committed to remain in C89. + +The goal now is to make the gRPC core implementation true idiomatic +C++ compatible with [Google's C++ style guide](https://google.github.io/styleguide/cppguide.html). ## Constraints @@ -48,7 +51,10 @@ The goal now is to make gRPC core true idiomatic C++ compatible with ## Implications for C++ API and wrapped languages -- For C++ structs, switch to `using` when possible (e.g., Slice, ByteBuffer, ...) +- For C++ structs, switch to `using` when possible (e.g., Slice, +ByteBuffer, ...) +- The C++ API implementation might directly start using +`grpc_transport_stream_op_batch` rather than the core surface `grpc_op`. - Can we get wrapped languages to a point where we can statically link C++? This will take a year in probability but that would allow the use of `std::` - Are there other environments that don't support std library, like maybe Android NDK? - Probably, that might push things out to 18 months |