-
Notifications
You must be signed in to change notification settings - Fork 359
feat(c++): support private fields of c++ class #3193
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
Open
chaokunyang
wants to merge
22
commits into
apache:main
Choose a base branch
from
chaokunyang:support_private_fields_of_cpp_class
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
feat(c++): support private fields of c++ class #3193
chaokunyang
wants to merge
22
commits into
apache:main
from
chaokunyang:support_private_fields_of_cpp_class
+815
−398
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
urlyy
approved these changes
Jan 23, 2026
dc1d81f to
27e78b6
Compare
PragmaTwice
approved these changes
Jan 23, 2026
Member
PragmaTwice
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven’t taken a deep dive yet, but it looks fine based on the test cases.
61a6348 to
5062f88
Compare
5062f88 to
425592e
Compare
… access violation On MSVC, using 'friend constexpr auto ForyFieldInfo(...)' inside polymorphic classes (classes with virtual functions) triggers RTTI access violations during serialization/deserialization. This causes tests like MaxDynDepthExceeded, MaxDynDepthSufficient, and NonDynamicFieldWithForyField to fail with 'Access violation - no RTTI data!' errors. The fix follows the pattern used by yaLanTingLibs YLT_REFL macro, which uses non-constexpr friend functions to avoid this MSVC issue while still keeping the macro inside the class body for private field access. Changes: - Changed 'friend constexpr auto ForyFieldInfo' to 'friend auto ForyFieldInfo' in both FORY_STRUCT_FIELDS and FORY_STRUCT_DETAIL_EMPTY macros Fixes smart_ptr_serializer_test failures on Windows Server 2022 MSVC.
Since ForyFieldInfo friend function is no longer constexpr to fix MSVC RTTI
issues with polymorphic types, tests that used 'constexpr auto info =
ForyFieldInfo(obj)' need to be updated.
Changed to use 'auto info = ForyFieldInfo(obj)' for runtime usage and
'constexpr auto constInfo = Type::ForyFieldInfoDescriptor{}' for compile-time
static assertions. The descriptor struct itself remains fully constexpr.
…RTTI access violation
The previous fix (removing constexpr) worked locally but failed on CI
with Windows Server 2022 MSVC. The issue is that directly constructing
ForyFieldInfoDescriptor in a friend constexpr function body causes
RTTI access violations for polymorphic types on MSVC.
This fix adds a static constexpr get() method to ForyFieldInfoDescriptor
and calls it from the friend function instead of direct construction:
Before (FAILED on CI):
friend auto ForyFieldInfo(...) noexcept {
return ForyFieldInfoDescriptor{...}; // RTTI error on polymorphic types
}
After (WORKS):
struct ForyFieldInfoDescriptor {
static constexpr auto get() noexcept { return ForyFieldInfoDescriptor{...}; }
};
friend constexpr auto ForyFieldInfo(...) noexcept {
return ForyFieldInfoDescriptor::get(); // No RTTI error
}
The indirection through a static method avoids MSVC's RTTI access issue
while preserving constexpr semantics. All 27 C++ tests pass locally.
Tests fixed:
- SmartPtrSerializerTest.MaxDynDepthExceeded
- SmartPtrSerializerTest.MaxDynDepthSufficient
- SmartPtrSerializerTest.NonDynamicFieldWithForyField
…C RTTI issues Changed polymorphic types in smart_ptr_serializer_test from using FORY_STRUCT inside the class to FORY_STRUCT_EXTERNAL outside the class. This avoids MSVC RTTI access violations when using friend constexpr functions with polymorphic types on Windows Server 2022. Types changed: - NestedContainer - NestedContainerHolder - PolymorphicBaseForMono - NonDynamicFieldHolder Also added static get() method to ForyFieldInfoDescriptor as part of earlier fix attempt (not the final solution but kept for consistency). The RTTI issue is specific to MSVC and occurs when FORY_STRUCT is used inside polymorphic classes with virtual methods. Using FORY_STRUCT_EXTERNAL (which defines the friend function outside the class) avoids this issue entirely. All 15 smart_ptr_serializer tests now pass locally.
…RY_STRUCT Replaced friend constexpr functions with static constexpr member functions following the YLT_REFL pattern. This completely avoids the MSVC RTTI access violation issue with polymorphic types. Changes: - FORY_STRUCT now defines: static constexpr auto ForyFieldInfo() noexcept - Removed friend keyword entirely from FORY_STRUCT macros - Added ForyFieldInfoHelper with SFINAE to forward calls from ForyFieldInfo(obj) to T::ForyFieldInfo() using C++17 std::void_t This approach is simpler, cleaner, and avoids all MSVC RTTI issues while maintaining the same functionality. All 25 C++ tests pass locally. The fix allows FORY_STRUCT to be used inside polymorphic classes without any issues on Windows Server 2022 / MSVC.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why?
The previous
FORY_FIELD_INFOmacro required defining field metadata outside the class/struct definition, which prevented it from accessing private fields. This limitation made it impossible to serialize classes with private members unless they were made public or friends were added.What does this PR do?
This PR introduces a new
FORY_STRUCTmacro that must be used inside the class/struct definition as a replacement forFORY_FIELD_INFO. The key changes include:FORY_STRUCTmacro: ReplacesFORY_FIELD_INFOand must be placed inside the struct/class body, enabling access to private fields via hidden friend functionsForyFieldInfo()as a friend function within the class, granting access to private membersFORY_STRUCT_FIELDSfor internal use and provides empty struct support viaFORY_STRUCT_EMPTYMigration pattern:
For external struct:
To include base-class fields in a derived type, list
FORY_BASE(Base)insideFORY_STRUCT. The base must define its ownFORY_STRUCTso its fields can bereferenced.
Related issues
#2906
Does this PR introduce any user-facing change?
Yes, this introduces a breaking API change requiring users to migrate from
FORY_FIELD_INFOtoFORY_STRUCT.Benchmark
No performance impact expected - this is a compile-time macro change that does not affect runtime serialization logic.