Resolve each flattened inherited attribute layout once after schema
initialization. Late-bound instance construction now follows descriptor
and index records directly instead of recursively traversing supertypes
and repeating derived and redefined attribute name searches.
Keep the cache outside EntityDescriptor so its object layout and API v1
ABI remain unchanged. Invalidate cached subtype layouts when descriptor
graphs are edited, and retain lazy preparation for non-module callers.
For the AP242e4 sample's most common entity, constructing 1,531,000
DIRECTION instances improved from 0.84s to 0.63s (-25.0%); user time
improved from 0.82s to 0.61s (-25.6%). Peak RSS increased by 0.9% and
libstepcore grew by 1.6%. Twenty full read/write runs remained at 4.9s.
The real file still created and validated 10,609 instances with zero
errors and warnings. Its 949,685-byte rewrite changed only by its
timestamp.
- API v2 table-driven schema, entity, type, attribute, and inheritance
initialization via include/clstepcore/ schemaInit.h.
- --late-bound/-T, producing descriptor-backed entities without
generated early-bound entity classes.
- CMake controls:
- SC_EXP2CXX_API_VERSION=2
- SC_EXP2CXX_LATE_BOUND=ON
- Runtime late-bound construction and owned attribute storage in
src/clstepcore/entityDescriptor.cc and src/clstepcore/STEPattribute.cc.
- Documentation and regression coverage, including incompatible option
handling.
AP242e4 generated-output results:
Mode Lines Bytes
━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━ ━━━━━━━━━━
Default v1 1,210,640 57.57 MB
──────────────────── ─────────── ──────────
API v2 early-bound 509,001 25.20 MB
──────────────────── ─────────── ──────────
API v2 late-bound 254,123 13.94 MB
The late-bound AP242 library compiled under C++11 and successfully
processed the BRL-CAD NIST sample: 10,609 instances
created and validated, with zero errors and warnings.
We want to be consistent with the previous layout, to avoid needlessly
breaking existing codes. The header update means client codes are not
required to include all of the stepcode library includes explicitly -
i.e., stepcode itself does not force this requirement with its own
internal includes. However, if client codes do not want to add the
library prefixes to their own includes as we have for stepcode, they
should still be able to add the various includes and work as before.
Adjust the include directory names accordingly.