diff options
| -rw-r--r-- | doc/core/moving-to-c++.md | 24 | ||||
| -rw-r--r-- | tools/doxygen/Doxyfile.core | 1 | ||||
| -rw-r--r-- | tools/doxygen/Doxyfile.core.internal | 1 |
3 files changed, 17 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 diff --git a/tools/doxygen/Doxyfile.core b/tools/doxygen/Doxyfile.core index b8514fe311..c8fd2ee48b 100644 --- a/tools/doxygen/Doxyfile.core +++ b/tools/doxygen/Doxyfile.core @@ -772,6 +772,7 @@ doc/connection-backoff-interop-test-description.md \ doc/connection-backoff.md \ doc/connectivity-semantics-and-api.md \ doc/core/grpc-error.md \ +doc/core/moving-to-c++.md \ doc/core/pending_api_cleanups.md \ doc/cpp-style-guide.md \ doc/environment_variables.md \ diff --git a/tools/doxygen/Doxyfile.core.internal b/tools/doxygen/Doxyfile.core.internal index ee593e3ea0..3047778737 100644 --- a/tools/doxygen/Doxyfile.core.internal +++ b/tools/doxygen/Doxyfile.core.internal @@ -772,6 +772,7 @@ doc/connection-backoff-interop-test-description.md \ doc/connection-backoff.md \ doc/connectivity-semantics-and-api.md \ doc/core/grpc-error.md \ +doc/core/moving-to-c++.md \ doc/core/pending_api_cleanups.md \ doc/cpp-style-guide.md \ doc/environment_variables.md \ |