Boost logo

Boost :

Subject: Re: [boost] Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-25 00:51:25

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.


Currently unemployed and looking for work.
Work Portfolio:

Boost list run by bdawes at, gregod at, cpdaniel at, john at