Allow specialisation of vsg::Inherit for sublasses #1609
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.
This allows default implementations of members to be provided, prevents copying and pasting of lots of trivial functions, and makes it possible to generate a compiler error if a subclass fails to provide a particular member without making it a pure virtual function.
This is a pretty close equivalent to how in the OSG, there was a
META_Objectmacro that did roughly what the VSG's Inherit template does, but also there were specialised macros likeMETA_NodeandMETA_StateAttributeto do extra things for particular kinds of object.I've only used this for
vsg::ArrayStateso far as that was the place where the problem came up in my work (I needed to add extracloneArrayStateoverloads and ensure subclasses overrode them). I think it's a fairly safe bet that there are other places where using this would be helpful, as I know I've been annoyed by the lack of such a feature in the past, although I can't remember when or why.This isn't the prettiest code in the world, and has a bonus extra annoying feature that it makes the Visual Studio debugger add an extra level of indentation to loads of things, but it's the best that can be done until P3469 https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3469r0.pdf is ratified and becomes part of C++ (it's too late to get into C++26) and finally makes CRTP fully obsolete.