vsg::Object cast<T>() sometimes returns nullptr on macOS Sonoma arm64 Release builds

[hearga]

Description

• Addressed an issue where vsg::Object::cast() would sometimes return nullptr on macOS Sonoma (Apple Silicon, arm64) in Release builds.
• Updated the casting logic to use dynamic_cast<T*>(), matching the approach already used in the previous function " template
  ref_ptr readObject(const char* propertyName)"

Type of change

• Bug fix (non-breaking change which fixes an issue)

[robertosfield]

We need to get to the bottom of why cast<> is failing, not go around relacing all of it's usage across the VSG.

Is that are particular object type that is failing?

[hearga]

I agree... I did, but I couldn't find anything.

The object type is uintArray, here

VulkanSceneGraph/src/vsg/text/Font.cpp

Line 30 in 28b6b81

input.readObject("charmap", charmap);

[robertosfield]

Could you have a look at this thread, I believe it touches upon the issue you are seeing:

#899

It looks like an issue with clang generating different type_info results for different libraries in certain circumstances. At the end of the above thread there are suggestions for solutions.

[hearga]

It works using explicit template instantiation. It resolves the different type_info hash IDs during casting.

[robertosfield]

Thanks for the changes, I've done a first past review and it feels like a rather heavy handed approach, forcing lots of extra code that we don't need other than for working around a problem with a specific compiler's build settings.

The changes would also need to be rolled out to all the other use of templates such as vsg::Value, Array2D, Array3D and perhaps even use of vsg::Inherit.

Did you test building as dynamic library?

[hearga]

Thanks for the review, I’ve reworked this to a minimal fix that targets the actual Clang issue (hidden visibility causing divergent &typeid(Array) across TUs):

• Export the class: Array to stabilize typeid.
• No explicit instantiations: removed ArrayInstantiations.cpp.
• Opt-in escape hatch: VSG_USE_DYNAMIC_CAST switches cast() to dynamic_cast for those who prefer it.

If this approach looks good, we can apply the same small change to Value, Array2D/Array3D, etc., as needed, no project-wide mass changes required.

Shared libs: not tested, sorry, I have limited time to work on this; in shared builds, we already define the import/export macro, so the type info should be default-visible and typeid stable—no additional changes expected.