Repository navigation
asf_dyn v0.1.5
This release builds on v0.1.4 with a clearer cache-adopt path for storing dereferenceable smart pointers inside cache_dyn, richer shallow pointer_ops, and an ABI bump to v0_1_5_b0110. Documentation adds a Why ASF section (flexible full-Ptr erasure vs single-handle proxy stacks) and updated pointer/cast specs.
What changed in v0.1.5
cache_storage_spec<Storage>— maps stored types tocache_ptrgeometry and default shallowOps(unique_ptr/shared_ptr,pointer_trait::ops, …), independent of adopt wrapperscache_deref<Ptr>(renamed fromproxy_wrap) — reference adopt wrapper forto_dyn: cache buffer holdsPtr, vtable dispatches on the pointee- Opt-in cache-adopt routing: nested
using asf_adopt_proxy = void(presence only; type not checked); same protocol can be implemented on user types to_dynusescache_ptr_for_storage<Ptr>when Spec is omitted for adopt wrappers (no Spec embedded in the wrapper)pointer_ops: unbound ops, duck-typed slots, shallowbool,vtable_ofintrospection- Internal cleanup of unused helpers;
is_cache_adopt_wrapperfix for move-from-adopt_storage()(Ptr&&) - Version / ABI:
0.1.5, inline ABI namespacev0_1_5_b0110(default feature tagb0110) - README (EN/ZH) and spec docs aligned for cache adopt,
adopt_storage,pointee
Breaking / migration (from v0.1.4)
proxy_wrap→cache_deref- Wrapper accessors:
pointer()→adopt_storage(); nodefault_cache_specon the wrapper — usecache_storage_specor an explicitcache_ptrSpec onto_dyn - Cache-adopt
to_dynrequiresasf_adopt_proxyon the wrapper type - Rebuild all translation units: ABI inline namespace changed
v0_1_4_*→v0_1_5_*
Why this release matters
v0.1.5 makes the “smart pointer in SBO cache, methods on the pointee” workflow explicit and extensible without baking buffer layout into a single library wrapper type. It keeps the forward-looking C++26 reflection direction while tightening pointer/c cache ergonomics for proxy-like benchmarks and production-shaped APIs.
Project status
asf_dyn remains an early-stage, standards-dependent library built around the emerging C++26 reflection model. It is not yet a broadly mature production dependency, but it is a deliberate and increasingly coherent codebase with a clear direction and ongoing refinement.
Compatibility and expectations
- Requires a C++26 reflection-capable toolchain
- Primary supported environment remains GCC 16 and related reflection-enabled setups
- Some advanced features remain compiler-sensitive or feature-gated
- API and behavior may continue to evolve as the underlying reflection ecosystem matures
- Do not mix v0.1.4 and v0.1.5 compiled objects in one process (ABI namespace change)
Known limitations
- Requires compiler support for the relevant C++26 reflection features
- Some configuration combinations remain experimental or intentionally restricted
- This is a source-based, header-oriented library rather than a binary distribution
- This release is part of the ongoing 0.1 development trajectory
License
Boost Software License 1.0