Set C++ version consistently to C++ 17 #1203

2022-12-29T20:05:05-08:00

NickGerleman commented

2022-12-29 20:05:05 -08:00

(Migrated from github.com)

Summary:
This sets the C++ standard to C++ 17 in the working builds and Apple. GTest will stop supporting C++ 11 soon, so we need to update. C++ 14 is more embeddable, but C++ 17 support and usage should be relatively common now and the language version adds quite a bit.

Changelog: [Internal]

Differential Revision: D42285391

Summary: This sets the C++ standard to C++ 17 in the working builds and Apple. GTest will stop supporting C++ 11 soon, so we need to update. C++ 14 is more embeddable, but C++ 17 support and usage should be relatively common now and the language version adds quite a bit. Changelog: [Internal] Differential Revision: D42285391

facebook-github-bot commented

2022-12-29 20:05:40 -08:00

(Migrated from github.com)

This pull request was exported from Phabricator. Differential Revision: D42285391

This pull request was **exported** from Phabricator. Differential Revision: [D42285391](https://www.internalfb.com/diff/D42285391)

facebook-github-bot commented

2022-12-29 20:09:56 -08:00

(Migrated from github.com)

This pull request was exported from Phabricator. Differential Revision: D42285391

This pull request was **exported** from Phabricator. Differential Revision: [D42285391](https://www.internalfb.com/diff/D42285391)

inobelar commented

2022-12-30 07:22:47 -08:00

(Migrated from github.com)

@NickGerleman Is it good to increase library build requirements so dramatically? (just because the internals in the library that tests the code of this library have changed?) Currently we have the next conditions:

Yoga is used via public C interface for portability across languages (we have no benefit from upgrading c++ version)
The library is essentially a set of mathematical algorithms, with heavy use of floating point operations (we do not benefit from a larger version of the language, because new language features and changes in stdlib are simply not used, and may be even never used, like string_view, or ranges)

Increasing the requirement for the language version - in our case, this is only a limitation. Yoga can now be used directly on a wide range of devices (without building into a library, by direct embedding into the project's source tree), even on embedded ones (like ESP32/IMX.6), where compilers are often not the most recent and offenly supports only c++11/c++14.

Increasing the language requirement does not add performance - newer versions of compilers generate more efficient code, but newer language is not about it.

Personally, I use Yoga in a very limited environment (with pretty old still good gcc 4.9.2, that knows only about c++11, and c++14 in experimental form) to make a low-latency medical GUI , very close to hardware, almost bare-metal , using OpenGL for rendering and gamedev-like optimization techniques. In such restricted environment (for specific software, in which we must control everything, each millisecond and each pixel on screen) most of the modern libraries (like freetype, harfbuzz, minikin, icu, flatbuffers, imgui, sdl2, glfw3, etc) compiles & works nicely (since them written in C or C++11)

I builded & tested Yoga on various tiny devices with armhf/aarch64 architecture, x86_64 and even in browser (via emscripten) - it everywhere works well, especially due to it's portability (low requirements for compiler, no special hardware requirements & hacks), like other cool tiny-but-extremely-useful projects imgui or stb, (or harfbuzz, which is low-requirements too).

I haven't tried it yet, but I'm sure Yoga will work in such unusual scenarios as "rendering GUI in VR" (native on perfomant HMD (like HTC Vive) and standalone (like Oculus Quest) browser-like), using, for example: c++, emscripten, SDL2 (for making WebGL canvas), OpenXR js-API port/bindings for c++ (for I/O), and WebGL for drawing.

I know these are very atypical scenarios, compared to using Yoga for React or mobile development, but I encourage you to think big.

IMHO, such significant changes must be agreed with the community, and thought out carefully, otherwise it will lead to the creation of a fork with support for c++11 for those who need it.

@NickGerleman Is it good to increase library build requirements so **dramatically**? (just because the internals in the library that tests the code of this library have changed?) Currently we have the next conditions: - Yoga is used via public C interface for portability across languages (we have no benefit from upgrading c++ version) - The library is essentially a set of mathematical algorithms, with heavy use of floating point operations (we do not benefit from a larger version of the language, because new language features and changes in stdlib are simply not used, and may be even never used, like `string_view`, or `ranges`) Increasing the requirement for the language version - in our case, this is only a **limitation**. `Yoga` can now be used directly on a wide range of devices (without building into a library, by direct embedding into the project's source tree), even on **embedded** ones (like ESP32/IMX.6), where compilers are often not the most recent and offenly supports only c++11/c++14. Increasing the language requirement does not add performance - newer versions of **compilers** generate more efficient code, but newer **language** is not about it. ---- Personally, I use `Yoga` in a very limited environment (with pretty old still good `gcc 4.9.2`, that knows only about c++11, and c++14 in experimental form) to make a low-latency medical GUI , very close to hardware, almost bare-metal , using `OpenGL` for rendering and gamedev-like optimization techniques. In such restricted environment (for specific software, in which we must control everything, each millisecond and each pixel on screen) most of the modern libraries (like freetype, harfbuzz, minikin, icu, flatbuffers, imgui, sdl2, glfw3, etc) compiles & works nicely (since them written in C or C++11) I builded & tested Yoga on various tiny devices with `armhf`/`aarch64` architecture, `x86_64` and even in browser (via `emscripten`) - it everywhere works well, especially due to it's **portability** (low requirements for compiler, no special hardware requirements & hacks), like other cool tiny-but-extremely-useful projects [imgui](https://github.com/ocornut/imgui) or [stb](https://github.com/nothings/stb), (or harfbuzz, which is low-requirements too). I haven't tried it yet, but I'm sure `Yoga` will work in such unusual scenarios as "rendering GUI in VR" (native on perfomant HMD (like HTC Vive) and standalone (like Oculus Quest) browser-like), using, for example: c++, emscripten, SDL2 (for making WebGL canvas), OpenXR js-API port/bindings for c++ (for I/O), and WebGL for drawing. I know these are very **atypical** scenarios, compared to using Yoga for React or mobile development, but I encourage you to think big. ---- IMHO, such significant changes must be agreed with the **community**, and thought out **carefully**, otherwise it will lead to the creation of a **fork with support for c++11** for those who need it.

NickGerleman commented

2022-12-30 15:06:47 -08:00

(Migrated from github.com)

GTest, apart from being a dependency, is a prompt that even foundational C++ libraries are now requiring versions newer than C++ 11. Bumping the language version brings in a lot of new changes which can simplify usage, and anecdotally just writing some code, I forgot how many things weren't available yet in C++ 11. A lot of constexpr we know today doesn't work at the current language version. Binary literals didn't exist until C++ 14. [[maybe_unused]] didn't exist until C++ 17.

I could imagine C++ 17 may be a step too far, but I also don't think the toolchains of microcontroller vendors are the lowest common denominator we want to be targeting in our latest builds either. It adds a lot of restriction, for a use-case of Yoga that seems pretty rare. Some of the other toolchains you mention like Emscripten are actually included in the validation of this change 😉.

I will change this so that we bump to C++ 14. If you want to fork to create a version targeting C++ 11, you are definitely welcome to.

GTest, apart from being a dependency, is a prompt that even foundational C++ libraries are now requiring versions newer than C++ 11. Bumping the language version brings in a lot of new changes which can simplify usage, and anecdotally just writing some code, I forgot how many things weren't available yet in C++ 11. A lot of `constexpr` we know today doesn't work at the current language version. Binary literals didn't exist until C++ 14. `[[maybe_unused]]` didn't exist until C++ 17. I could imagine C++ 17 may be a step too far, but I also don't think the toolchains of microcontroller vendors are the lowest common denominator we want to be targeting in our latest builds either. It adds a lot of restriction, for a use-case of Yoga that seems pretty rare. Some of the other toolchains you mention like Emscripten are actually included in the validation of this change 😉. I will change this so that we bump to C++ 14. If you want to fork to create a version targeting C++ 11, you are definitely welcome to.

👍 1

inobelar commented

2022-12-30 16:19:15 -08:00

(Migrated from github.com)

@NickGerleman thanks for your response. Happy Holidays!

facebook-github-bot commented

2023-01-08 11:19:24 -08:00

(Migrated from github.com)

This pull request was exported from Phabricator. Differential Revision: D42285391

This pull request was **exported** from Phabricator. Differential Revision: [D42285391](https://www.internalfb.com/diff/D42285391)

facebook-github-bot commented

2023-01-10 09:45:56 -08:00

(Migrated from github.com)

This pull request has been merged in facebook/yoga@53a8842abb.

This pull request has been merged in facebook/yoga@53a8842abb3df5877b1b2c6ccf935561282ced68.

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: DaddyFrosty/yoga#1203