Skip to content

Conversation

@chaokunyang
Copy link
Collaborator

@chaokunyang chaokunyang commented Jan 23, 2026

Why?

The previous FORY_FIELD_INFO macro 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_STRUCT macro that must be used inside the class/struct definition as a replacement for FORY_FIELD_INFO. The key changes include:

  1. New FORY_STRUCT macro: Replaces FORY_FIELD_INFO and must be placed inside the struct/class body, enabling access to private fields via hidden friend functions
  2. Hidden friend function approach: Uses ADL (Argument-Dependent Lookup) to define ForyFieldInfo() as a friend function within the class, granting access to private members
  3. Backward compatibility: Keeps FORY_STRUCT_FIELDS for internal use and provides empty struct support via FORY_STRUCT_EMPTY
  4. Comprehensive migration: Updates all usages across:
    • Test files (encoder, serialization, field tests)
    • Documentation (C++ row format guide, xlang spec)
    • Examples (hello_row example)
    • README files

Migration pattern:

// Before:
struct MyClass {
  int private_field;
};
FORY_FIELD_INFO(MyClass, private_field);  // Outside class, no access to private

// After:
struct MyClass {
  int private_field;
  FORY_STRUCT(MyClass, private_field);  // Inside class, can access private
};

For external struct:

namespace thirdparty {
struct Foo {
  int32_t id;
  std::string name;
};

FORY_STRUCT_EXTERNAL(Foo, id, name);
} // namespace thirdparty

auto fory = Fory::builder().build();
fory->register_struct<thirdparty::Foo>(1);

To include base-class fields in a derived type, list FORY_BASE(Base) inside
FORY_STRUCT. The base must define its own FORY_STRUCT so its fields can be
referenced.

struct Base {
  int32_t id;
  FORY_STRUCT(Base, id);
};

struct Derived : Base {
  std::string name;
  FORY_STRUCT(Derived, FORY_BASE(Base), name);
};

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_INFO to FORY_STRUCT.

  • Does this PR introduce any public API change?
  • Does this PR introduce any binary protocol compatibility change?

Benchmark

No performance impact expected - this is a compile-time macro change that does not affect runtime serialization logic.

@chaokunyang chaokunyang changed the title feat(c++): support private fields of cpp class feat(c++): support private fields of c++ class Jan 23, 2026
@chaokunyang chaokunyang force-pushed the support_private_fields_of_cpp_class branch 4 times, most recently from dc1d81f to 27e78b6 Compare January 23, 2026 14:17
Copy link
Member

@PragmaTwice PragmaTwice left a 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.

@chaokunyang chaokunyang force-pushed the support_private_fields_of_cpp_class branch from 61a6348 to 5062f88 Compare January 24, 2026 14:16
@chaokunyang chaokunyang force-pushed the support_private_fields_of_cpp_class branch from 5062f88 to 425592e Compare January 24, 2026 15:19
… 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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants