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
Vijay Pai
7 years ago