I'm trying to think how to specify the primitives and specifically I want to know if it is feasible to require implementations to provide an integral ID for a type?
I think it would be very advantageous if this could be arranged, especially if the numbers could be guaranteed to be "small positive” ints
so that a vector or similar can be indexed by the type id number without risk that the vector is suddenly gigabytes in size due to large holes in the number series.
This would allow very fast lookup of per-type information that may be needed for instance for serialization etc. and no the least for a RTTI system built on top of the CTTI system.
The current run-time equivalent use cases of the minimum functionality (name, hashable, comparable) are roughly:
If type_id_number<T> is feasible the later two could be implemented pure library as:
typeid strips the cv-qualifiers and reference from the type, we would like to leave them to the user to decide whether to apply the appropriate remove traits.
typeid also returns a reference, so requiring that this be a reference constant expression could interact badly with the dynamic version of typeid.
Also specifying std::type_info as a literal type when it is polymorphic is non-trivial.
My current feeling about this is that there might be a separate interface equivalent std::static_type_info<T> class template that provides these functions as static functions or variables - or, more likely, that all three would be three separate type traits in the usual form.
The type_info objects from various TUs would need to be merged. This problem is why typeid has slightly weird semantics. But it seems it already must be solved for a platform to support variable templates, so maybe typeid should be tidied up as well.
My impression is that hash_value already just gives you a suitably casted address of a typeinfo object. The easiest way out of all this is probably just to verify that's a suitable spec, and specify it just as such.
On Sunday, March 30, 2014 3:26:37 AM UTC+8, Andrew Tomazos wrote:If type_id_number<T> is feasible the later two could be implemented pure library as:
Obviously we can't have a perfect hash of types to integers because integers are bounded and types aren't.
typeid strips the cv-qualifiers and reference from the type, we would like to leave them to the user to decide whether to apply the appropriate remove traits.
They won't be stripped if inside a template argument, so I'd recommend taking the id of identity< T > in the corner cases where you want to preserve top-level reference and const. Also note that expressions don't have reference type and scalar expressions don't have top-level const; those things are only re-added by decltype.
typeid also returns a reference, so requiring that this be a reference constant expression could interact badly with the dynamic version of typeid.
It returns an lvalue; expressions don't have reference type. Presumably it's already a reference constant expressions since it's allowed in a constant expression, but this point should be clarified.
Also specifying std::type_info as a literal type when it is polymorphic is non-trivial.
type_info does not behave differently for polymorphic types. They have more internal RTTI properties but I don't see the relevance or the problem.
My current feeling about this is that there might be a separate interface equivalent std::static_type_info<T> class template that provides these functions as static functions or variables - or, more likely, that all three would be three separate type traits in the usual form.
Why not let std::static_type_info<T> be a variable template of invariant type? It seems like the application for which variable templates were invented.
To be clear: variable templates solve the compile-time identifier-value issue, because you can use the address of the variable template instantiation.
As for solving the problem at hand, rather than mucking about with compile time strings, it might be better to make constexpr typeinfo::operator== and before. The latter forces the collation order not to depend on addresses though, but rather something like strcmp. To avoid disturbing ABIs, it might be better to introduce operator< instead with a potentially different ordering. (While we’re at it, make it a non-member!)