Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using STD library for API surface #374

Merged
merged 73 commits into from
Dec 22, 2020
Merged

Using STD library for API surface #374

merged 73 commits into from
Dec 22, 2020

Conversation

maxgolov
Copy link
Contributor

I created a separate design doc to explain the logic and what's done in docs/building-with-stdlib.md

@jsuereth

@maxgolov maxgolov requested review from a team and jsuereth October 26, 2020 21:41
@codecov
Copy link

codecov bot commented Oct 26, 2020

Codecov Report

Merging #374 (2dc2313) into master (5e946f9) will increase coverage by 0.04%.
The diff coverage is 96.91%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #374      +/-   ##
==========================================
+ Coverage   94.40%   94.44%   +0.04%     
==========================================
  Files         187      187              
  Lines        8234     8233       -1     
==========================================
+ Hits         7773     7776       +3     
+ Misses        461      457       -4     
Impacted Files Coverage Δ
.../include/opentelemetry/common/key_value_iterable.h 100.00% <ø> (ø)
api/include/opentelemetry/logs/logger.h 100.00% <ø> (ø)
api/include/opentelemetry/nostd/function_ref.h 77.77% <ø> (ø)
api/include/opentelemetry/nostd/shared_ptr.h 100.00% <ø> (ø)
api/include/opentelemetry/nostd/span.h 89.36% <ø> (+1.36%) ⬆️
api/include/opentelemetry/nostd/string_view.h 97.50% <ø> (ø)
api/include/opentelemetry/nostd/unique_ptr.h 100.00% <ø> (ø)
api/include/opentelemetry/nostd/utility.h 83.33% <ø> (ø)
api/include/opentelemetry/trace/span.h 100.00% <ø> (ø)
api/test/nostd/string_view_test.cc 100.00% <ø> (ø)
... and 12 more

tools/setup-buildtools.sh Outdated Show resolved Hide resolved
Copy link
Contributor

@jsuereth jsuereth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks pretty good. I'm taking a crack at seeing if I can expose the same flexibility in the bazel-build without too much effort.

.gitmodules Outdated Show resolved Hide resolved
api/include/opentelemetry/std/span.h Show resolved Hide resolved
docs/building-with-stdlib.md Outdated Show resolved Hide resolved
docs/building-with-stdlib.md Outdated Show resolved Hide resolved
docs/building-with-stdlib.md Show resolved Hide resolved
docs/building-with-stdlib.md Outdated Show resolved Hide resolved
docs/building-with-stdlib.md Outdated Show resolved Hide resolved
@maxgolov maxgolov requested a review from ThomsonTan December 10, 2020 22:28
@maxgolov
Copy link
Contributor Author

maxgolov commented Dec 10, 2020

@jsuereth @lalitb @ThomsonTan - I think I'm kinda done with this, with the following follow-ups that I will send in a separate PR:

  • a document that explains how to cook the two flavors with CMake in Visual Studio 2019 on Windows.
  • description of how tools/build.sh can be used to build either nostd or stdlib flavor of SDK on Linux and Mac.
  • and also adding CI loop for stdlib flavor, to ensure that we do not introduce unintentional regressions in new code.

The only part that I feel a bit uneasy about is CMakeList.txt - adding ${CORE_RUNTIME_LIBS} variable in a few spots. And it is only set only if compiling with WITH_ABSEIL for variant implementation. Basically it's an implementation of an exception handler in case if variant throws nostd::bad_variant_access. I tried to explain it in a comment here - https://github.com/open-telemetry/opentelemetry-cpp/pull/374/files#r512342232 - and this will be needed to resolve this issue later on: #215 #314 .. Right now we cannot compile with Visual Studio 2015 at all. Only Abseil variant (absl::variant) would work. I can take care of it in a fix for #215 ... if you feel like we'd rather remove these changes in CMakeList.txt - I can remove and send in a separate PR.. but it's kinda benign, because right now we don't set that variable at all yet. So it has no effect. Maybe we have to include this functionality in some sort of opentelemetry-common.a library, and require that instead of requiring ${CORE_RUNTIME_LIBS}.

I also owe a spreadsheet with benchmark results. I added the benchmark, btw. But it'd be nice to illustrate the real benefits in a real-world test case. There could be some further optimization applied on API surface, when we know that a collection is one of standard types and when exporter can operate on a standard type, not needing an intermediate KeyValueIterable. This will be applicable to use-case when the SDK is compiled on Windows with ETW exporter. I also added a blurb that explains that on Windows - ABI compatibility is generally not an issue for Visual Studio 2015/2017/2019, so products operating on Windows and built with Visual Studio may rather prefer to use SDK build with stdlib flavor, esp. since Visual Studio 2019 product builds won't even need any non-standard types from our backport : all C++20 types used by SDK are available in Visual Studio toolchain-provided C++ runtime.

Copy link
Contributor

@jsuereth jsuereth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would like to cleanup all the benchmark code, but otherwise looking forward to pushing this to the next level!

api/test/nostd/BUILD Outdated Show resolved Hide resolved
api/test/nostd/shared_ptr_test.cc Outdated Show resolved Hide resolved
api/test/nostd/span_test.cc Outdated Show resolved Hide resolved
api/test/nostd/string_view_test.cc Outdated Show resolved Hide resolved
docs/building-with-stdlib.md Outdated Show resolved Hide resolved
docs/building-with-stdlib.md Show resolved Hide resolved
Copy link
Member

@lalitb lalitb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM overall. Somewhat large PR, but thanks for documenting the changes, and clarifying ABI related issues we will have with stl.

#include <type_traits>
#ifdef HAVE_CPP_STDLIB
# include "opentelemetry/std/span.h"
#else
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be check forHAVE_ABSEIL macro too, and include absl/span.h if set.

Copy link
Contributor Author

@maxgolov maxgolov Dec 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was unconditionally using either std::span or gsl::span since GSL span implementation is guaranteed to be 100% conformant, whereas absl::Span is not guarnateed to be conformant. I added a brief description to the markdown document.... Basically for now I'd use variant from absl::variant , because there is no other option that would compile with Visual Studio 2015. But not using absl for Span. I can see if we can use that in a separate PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#include <string>
#ifdef HAVE_CPP_STDLIB
# include "opentelemetry/std/string_view.h"
#else
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check for HAVE_ABSEIL ?

Copy link
Contributor Author

@maxgolov maxgolov Dec 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not yet. I'm not adding full HAVE_ABSEIL support, planning to only use that for absl::variant with Visual Studio 2015. For string_view we only support nostd::string_view and std::string_view. No support for absl::string_view here.

In all other build systems we prefer the following - in the following order, when HAVE_CPP_STDLIB feature is enabled:

  • prefer standard std:: classes in C++14, C++17, C++20
  • prefer gsl::span for C++11, C++14, C++17. GSL is the only fully conforming implementation. absl::Span is NOT 100% standards -conforming. I described this in the markdown doc.
  • prefer absl::variant for v2015: technically this is needed only for C++11 on Windows with vs2015. C++17 already has std::variant. We should eventually remove MPark variant (nostd::variant). And borrow absl::variant instead of MPark variant.

Otherwise our builds will not work with anything that is compiled with vs2015. I kept MPark variant for now. Basically, Abseil is only needed for variant, and absl::variant itself is only needed for vs2015 support. I did foundation work to resolve these issues: #215 #314

I'll add vs2015 in CI in a separate PR. There is no default runner with vs2015 on GitHub. Installing build tools of that may take considerable amount of time in CI. Gotta be creative to sort out how to deploy it the fastest way.

docs/abi-compatibility.md Show resolved Hide resolved
@owent owent mentioned this pull request Dec 19, 2020
@maxgolov maxgolov added the pr:please-merge This PR is ready to be merged by a Maintainer (rebased, CI passed, has enough valid approvals, etc.) label Dec 21, 2020
@lalitb lalitb merged commit 1e7b9d8 into master Dec 22, 2020
kxyr pushed a commit to open-o11y/opentelemetry-cpp that referenced this pull request Dec 22, 2020
kxyr pushed a commit to open-o11y/opentelemetry-cpp that referenced this pull request Dec 22, 2020
owent added a commit to owent/opentelemetry-cpp that referenced this pull request Dec 23, 2020
owent added a commit to owent/opentelemetry-cpp that referenced this pull request Dec 29, 2020
@reyang reyang deleted the maxgolov/nostd_stl branch January 20, 2021 23:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr:please-merge This PR is ready to be merged by a Maintainer (rebased, CI passed, has enough valid approvals, etc.)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Simple processor and Simple Log processor use a non-standard feature deprecated in C++20
4 participants