On 25 Nov 2013 at 17:13, Gavin Lambert wrote:
I'm fairly sure what Niall was proposing was a copyable object -- ie. basically the same semantics as the current proposed boost::type_index but storing data directly within rather than via indirection to boost::type_info, which would no longer exist.
Exactly right. Only thing missing is that I would have boost::type_index have sizeof=0 i.e. pure static data only.
That sounds like a reasonable design to me. (It does mean code using the address-of-type_info as a key would have to change to use value-of-type_index instead, but that's probably safer anyway.)
Correct. My proposed boost::type_index is completely unrelated to anything in the STL, and if you use its comparison operators it will do the right thing. Taking its address, if of the const lref returned by boost::type_id<>, will be no more unreliable that taking the address of a std::type_info.
Caching the name internally as a static member complicates the design (the cache has to be thread-safe and be accessible in global constructors/destructors). Caching the name as a regular member is unacceptable bloat (people expect type_index to be as light as a pointer to type_info; no dynamic memory allocation and associated possible exceptions are allowed).
That does raise a good point.
I've never had a problem here in my own code. Static data defaults to zero, so you do an atomic CAS to serialise construction on first use. I agree one is firing and forgetting the allocation though, and I would in my own code annotate the allocation with valgrind instrumentation to tell valgrind it's not a leak. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/