Support for general types inside static_var #101
Merged
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 change set adds a major feature which allows wrapping static_var around arbitrary types that have a copy constructor and == defined. This is required for wrapping STL types like vectors and maps into static_var.
With this, we also deprecate using tag.stringify() as a unique representation of tag since some types cannot be stringified. All (unordered) maps and sets now directly use tag as an index. To support this a std::hash implementation has been added for tags. The objects that cannot be hashed are not included in the hash, which could also collisions, but that is okay since hashes are expected to be completely unique, the == operator does handle correctness.
The hash implementation caches hashes as much as possible to avoid overheads and virtual dispatches. Finally, the snapshots that are part of the static tag are now heap allocated and shared using shared_ptr.
TODO: add caching to static_var so that new snapshot isn't generated everytime if the object hasn't changed.
Limitations: When aggregate types are wrapped in static_var, they don't automatically convert when members are accessed. So they still need to be accessed as static_var.val.member(). In this future this can be fixed by making static_var inherit from T in case of aggregate types just like dyn_var.
sample65 has been added to test this.