gRPC starts requiring C++14 from v1.47.0

[lalitb]

We should discuss this in the next community meeting on how to proceed further.

• gRPC C++ 1.46 will be the last release supporting C++11, future releases will require C++ >= 14.
• otel-cpp supports C++11, this would mean that we may not be able to build otlp-cpp + otlp-grpc exporter with C++11 compiler after upgrading to gRPC 1.47.

Once gRPC v1.47 is released, one of the safe options would be to document this constraint clearly. So there would be two constraints with gRPC

• Building otel-cpp with gRPC v1.38+ fails when using gcc4.8 compiler (with -std=c++11). (known issue - already documented)
• Building otel-cpp with gRPC v1.47+ fails when using C++11 or lower compiler. (new issue )

Also, we can discuss if we want otel-cpp to use C++14, as most modern C++ compilers (GCC 5.0+, Clang 3.4+, VS2017+) support it. Interesting to know if there are any C++14 features we would like to really use ( at least not std::make_unique :) ) to make this a valid use case.

@owent - As you won't be able to join the community meeting if you would like to share your thoughts here :).

Reference

• https://github.com/grpc/grpc/releases/tag/v1.46.0
• https://github.com/grpc/proposal/blob/master/L98-requiring-cpp14.md

[owent]

Thanks.
We still have a lot environment in our company using gcc 4.8(CentOS 7), so for my selfish opnion, I still want to support gcc 4.8 which support c++11 only.
At my suggestion, I think we can maintain a building matrix to use gRPC 1.33.2, abseil-cpp 20200225.3 and protobuf 3.13.0 for gcc 4.8/bazel 3 and other legacy toolchains.And use the modern version of third parties with modern compilers(gcc 5.0+, clang 3.4+, VS2017+, bazel 4+).
About the aspect of syntactic sugar in c++14. I perfer to use GSL, e.g. use gsl::make_unique to replace std::make_unique in C++14. gsl-lite has the simular APIs with [MS-GSL] and has a better compatibilty for old compilers (gcc 4.8 for example).Maybe we can also add a CI job to use gsl-lite and enable HAVE_GSL.

[marcalff]

Thanks for the notice.

The selfish part:

In our build environment at company, we require C++ 17 already, so:

• no objections to support only C++ >= 14 in otel-cpp
• no objections to support only gRPC >= v1.47+ in otel-cpp
  if we have to or want to.

Without any other constraints to consider,
this would be the ideal choice.

The community part:

Now, considering everyone constraints ...

For the otel-cpp code itself,
no strong need identified to use C++ 14,
so keeping the otel-cpp code compatible with C++11 is ok,
if others have a need for C++ 11 only.

For keeping support for "old" dependencies like gRPC < 1.47,
no objections, as long as it does not prevent to use gRPC >= v1.47+.

In the worst case scenario, not opposed to have:

• #ifdef in the code related to gRPC, if it comes to it,
• separate gRPC exporter libraries, if it comes to it,
  but not asking for this (and hoping otel-cpp can avoid this extra complexity).