Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov

Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2013-11-16 18:41:55

On Tue, Nov 12, 2013 at 8:34 PM, Niall Douglas <s_sourceforge_at_[hidden]>wrote:

> Boost community feedback is requested for the formal peer review of
> the TypeIndex library by Antony Polukhin. Feedback requested
> includes:
>
> 1. Should this library be accepted into Boost?
>
>
YES.
First, because the documentation clarified issues I do have but didn't
realized I have yet (I guess I would have found out once I start porting my
project to another compiler).
I do use a lot of type_index as keys in different containers (including tbb
concurrent associative containers) and
a lot of the ids will come from runtime shared libraries loaded and
unloaded when needed.  (mostly I use them in different type-based message
dispatching systems)
So the documentation was a surprise and I'm happy to see that there are
potential solutions.
Second: I'm ok with either way of doing, to make boost::type_id and
boost::type_index similar to std:: ones or to have a more consistent
behaviour across platforms for boost ones.
I'm not sure which one is preferable, but I would make sure to use in my
own code the way that would allow me to have the exact (or almost exact)
same behaviour whatever the platform (if possible).
Whatever the way this library ends, I think I should used it as, as I was
saying, I'm using a lot type index.

One question though, I'm not totally clear if there is a remarkable
difference in performance and binary size between with RTTI using std and
without RTTI using this library.
I understand that performance wasn't the concern but I might have missed
useful indication on potential consequences of using this library.

I read most of the documentation though I think I should re-read some parts
as I was interrupted frequently through my reading.

> 2. Any conditions which should be attached to acceptance into Boost
> e.g. fixes, additional testing, changes to documentation. Please be
> as specific as possible here (bullet points are good!)
>
>
I don't have a particular condition, I'm not knowledgeable enough in the
details of the library to even participate to the discussion.