Hi Sylwester, Apache IoTDB’s C++ client currently builds and embeds Thrift 0.24.0, and both the client and generated Thrift code are built as C++11 today.
Our main concern is Visual Studio 2017. IoTDB currently publishes separate C++ client packages for VS2017, VS2019 and VS2022. VS2017 supports /std:c++17 and some of the library facilities mentioned in THRIFT-6364, but it does not have complete C++17 conformance, and the toolchains listed in the proposal only mention VS2022. Does Thrift intend to continue supporting VS2017/MSVC 14.1 after this change? If possible, could a VS2017 build be added to CI, or could the minimum supported MSVC version be documented explicitly? If VS2017 can still build and pass the C++ test suite, we do not expect this change to remove any platform currently supported by IoTDB. Otherwise, we would need to keep an older Thrift version or reconsider our VS2017 package. Thanks, Hongzhigao On 2026/09/27 13:35:44 Sylwester Lachiewicz wrote: > Hi all, > > I would like to check if we should raise the minimum C++ level of lib/cpp > and of the generated C++ code from C++11 to C++17, > Details are in THRIFT-6364: > https://issues.apache.org/jira/browse/THRIFT-6364 > > Why now: > > - Every toolchain we build with supports C++17 fully: GCC 11 and 13 in the > Ubuntu images, Visual Studio 2022, current Apple Clang. So does GCC 8, the > system compiler of RHEL 8. > - It lets lib/cpp replace most of its remaining Boost uses (tokenizer, > string algorithms, shared_array, numeric_cast, scope_exit, uuid) with the > standard library, which gets us close to what the README has promised since > 0.13.0: no Boost needed to build the library. TMultiplexedProcessor.h, a > public header, still pulls in boost/tokenizer.hpp today. > > What it costs: Since generated code includes our headers, users would have > to build their code as C++17 or later. Anyone still using C++11 or C++14 > would need to stay on an older version. > I am not proposing C++20: it would drop GCC 8 and 9 for little gain in a > serialization library. > > The change itself is small (the CMake default, configure.ac, the PHP and > Python extension flags, and the docs). > Master already builds unchanged with CMAKE_CXX_STANDARD=17 and passes the > C++ test suite on GCC 11.4 (Ubuntu 22.04) and Apple Clang. > Each Boost replacement would follow as its own ticket. > > Does anyone depend on building Thrift C++ as C++11 or C++14, or know of a > platform we would lose? > > Thanks, > Sylwester >
