Commit 36f94b6
authored
chore: remove leftover CMake checks for std::string_view (#1676)
* ci: suppress Node 20 deprecation and missing python-version warnings
- Injects `FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true` in all workflows to
opt-in to Node.js 24 and suppress the deprecation warnings from
multiple GitHub Actions.
- Specifies `python-version: '3.x'` for `actions/setup-python@v5` in
`meson.yml` to fix the missing input warning.
* Fix C++11 ABI breakage when compiled with C++17 (#1668)
When JSONCPP_HAS_STRING_VIEW was defined, the library dropped the
`const char*` and `const String&` overloads for `operator[]`, `get`,
`removeMember`, and `isMember`, breaking ABI compatibility for projects
consuming the library with C++11.
This change unconditionally declares and defines the legacy overloads
so they are always exported, restoring compatibility.
* ci: add ABI compatibility matrix workflow
This adds a new GitHub Actions workflow to verify ABI compatibility across C++ standard boundaries. It explicitly tests the scenario where JsonCpp is built with one standard (e.g., C++11) and consumed by an application built with a newer one (e.g., C++23), and vice versa.
To facilitate testing the specific `std::string_view` boundary that is conditionally compiled, a new `stringView` demo application has been added to the `example/` directory and is consumed directly by the CI matrix to ensure standard library symbols link correctly across standard versions, build types (shared/static), and operating systems.
* fix: inline std::string_view methods to prevent ABI breaks
This commit completely eliminates the ABI breakage that occurs across C++ standard boundaries when using `std::string_view`.
Previously, when the library was built with C++17+, CMake would leak `JSONCPP_HAS_STRING_VIEW=1` as a PUBLIC definition. A C++11 consumer would receive this definition, attempt to parse the header, and fail with compiler errors because `std::string_view` is not available in their environment.
Conversely, if the library was built in C++11 (without `string_view` symbols), a C++17 consumer would naturally define `JSONCPP_HAS_STRING_VIEW` based on `__cplusplus` inside `value.h`. The consumer would then call the declared `string_view` methods, resulting in linker errors because the methods weren't compiled into the library.
By moving all `std::string_view` overloads directly into `value.h` as `inline` methods that delegate to the fundamental `const char*, const char*` methods:
1. The consumer's compiler dictates whether the overloads are visible (via `__cplusplus >= 201703L`).
2. The consumer compiles the inline wrappers locally, removing any reliance on the library's exported symbols for `std::string_view`.
3. CMake no longer needs to pollute the consumer's environment with PUBLIC compile definitions.
* run clang format
* finish clang format
* chore: remove leftover CMake checks for std::string_view
Fixes #1669
This removes the final vestige of the JSONCPP_HAS_STRING_VIEW build system logic.
As of the previous commit (inlining std::string_view methods into value.h to fix ABI breaks), the library no longer relies on the build system (CMake or Meson) to check for and define JSONCPP_HAS_STRING_VIEW.
The header value.h automatically activates std::string_view overloads purely by checking the consumer`s __cplusplus >= 201703L. Since none of the actual std::string_view symbols are compiled into the .so / .a library anymore, Meson (and CMake) builds are identical regardless of whether string_view is supported by the compiler building the library.
* format spacing better1 parent c67034e commit 36f94b6
2 files changed
+0
-10
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
7 | 7 | | |
8 | 8 | | |
9 | 9 | | |
10 | | - | |
11 | 10 | | |
12 | 11 | | |
13 | 12 | | |
| |||
26 | 25 | | |
27 | 26 | | |
28 | 27 | | |
29 | | - | |
30 | | - | |
31 | | - | |
32 | | - | |
33 | | - | |
34 | 28 | | |
35 | 29 | | |
36 | 30 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
17 | 17 | | |
18 | 18 | | |
19 | 19 | | |
20 | | - | |
21 | | - | |
22 | | - | |
23 | | - | |
24 | 20 | | |
25 | 21 | | |
26 | 22 | | |
| |||
0 commit comments