2013/11/13 Niall Douglas <...>

On 12 Nov 2013 at 11:59, Robert Ramey wrote:

...

On Tuesday, November 12, 2013 11:34:27 AM UTC-8, Niall Douglas wrote:

...

Boost community feedback is requested for the formal peer review of the TypeIndex library by Antony Polukhin. Feedback requested includes ...

The above phrasing is a little unclear to me. Is this is a formal review of the library?

Yes, it's a formal review.

...

I've just glanced over the documentation but I do have a couple of questions.

The serialization library contains a component "extended_typeinfo". Am I correct in my understanding that this component is meant to address the same issues that extended_typeinfo does? If so, how are the two solutions different?

In short: * extended_typeinfo is not compatible with std::type_info and is hard to use * TypeIndex is a correctly working std::type_info that does not require RTTI + has other bonuses * detail/sp_typeinfo.hpp implements part of TypeIndex functionality, without workarounds for compiler issues Longer description: Serialization library is created to make a storeable in archive and portable between compilers type identifications. It's interface is not close to the interface of Standard Library, it requires A LOT of code to make typeids work (see example at http://www.boost.org/doc/libs/1_55_0/boost/serialization/extended_type_info_... ) TypeIndex is designed to be simple, fast and lightweight. It's a drop-in replacement for std::type_info with big set of workarounds for issues of different compilers and an extension to get human readable type names + it contains a C++11 type_index class and works without RTTI. It does not require user's support code to work. Take a look at this page: http://apolukhin.github.io/type_index/boost_typeindex/getting_started.htmlto see how Standard Library classes and methods are mapped to the TypeIndex ones. TypeIndex is close to detail/sp_typeinfo.hpp (it's just a very very enchanted sp_typeinfo that does not adds macro, embeds workarounds and has interface of std::type_info + other features from paragraph above) -- Best regards, Antony Polukhin