1 # Moving gRPC core to C++ 2 3 October 2017 4 5 ctiller, markdroth, vjpai 6 7 ## Background and Goal 8 9 gRPC core was originally written in C89 for several reasons 10 (possibility of kernel integration, ease of wrapping, compiler 11 support, etc). Over time, this was changed to C99 as all relevant 12 compilers in active use came to support C99 effectively. 13 [Now, gRPC core is C++](https://github.com/grpc/proposal/blob/master/L6-allow-c%2B%2B-in-grpc-core.md) 14 (although the code is still idiomatically C code) with C linkage for 15 public functions. Throughout all of these transitions, the public 16 header files are committed to remain in C89. 17 18 The goal now is to make the gRPC core implementation true idiomatic 19 C++ compatible with 20 [Google's C++ style guide](https://google.github.io/styleguide/cppguide.html). 21 22 ## Constraints 23 24 - No use of standard library 25 - Standard library makes wrapping difficult/impossible and also reduces platform portability 26 - This takes precedence over using C++ style guide 27 - But lambdas are ok 28 - As are third-party libraries that meet our build requirements (such as many parts of abseil) 29 - There will be some C++ features that don't work 30 - `new` and `delete` 31 - pure virtual functions are not allowed because the message that prints out "Pure Virtual Function called" is part of the standard library 32 - Make a `#define GRPC_ABSTRACT {GPR_ASSERT(false);}` instead of `= 0;` 33 - The sanity for making sure that we don't depend on libstdc++ is that at least some tests should explicitly not include it 34 - Most tests can migrate to use gtest 35 - There are tremendous # of code paths that can now be exposed to unit tests because of the use of gtest and C++ 36 - But at least some tests should not use gtest 37 38 39 ## Roadmap 40 41 - What should be the phases of getting code converted to idiomatic C++ 42 - Opportunistically do leaf code that other parts don't depend on 43 - Spend a little time deciding how to do non-leaf stuff that isn't central or polymorphic (e.g., timer, call combiner) 44 - For big central or polymorphic interfaces, actually do an API review (for things like transport, filter API, endpoint, closure, exec_ctx, ...) . 45 - Core internal changes don't need a gRFC, but core surface changes do 46 - But an API review should include at least a PR with the header change and tests to use it before it gets used more broadly 47 - iomgr polling for POSIX is a gray area whether it's a leaf or central 48 - What is the schedule? 49 - In Q4 2017, if some stuff happens opportunistically, great; otherwise \\\_()\_/ 50 - More updates as team time becomes available and committed to this project 51 52 ## Implications for C++ API and wrapped languages 53 54 - For C++ structs, switch to `using` when possible (e.g., Slice, 55 ByteBuffer, ...) 56 - The C++ API implementation might directly start using 57 `grpc_transport_stream_op_batch` rather than the core surface `grpc_op`. 58 - 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::` 59 - Are there other environments that don't support std library, like maybe Android NDK? 60 - Probably, that might push things out to 18 months 61
