November 2013 - Boost-announce - lists.stage.boost.cppalliance.org

Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013
by Niall Douglas 24 Nov '13

24 Nov '13

Please let me know as soon as possible any errata, missing credits etc. Niall Boost Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013 This report is the first edition, dated Sunday 24th November 2013. The review manager was Niall Douglas http://www.nedprod.com/. Source: https://github.com/apolukhin/type_index/zipball/master Documentation: http://apolukhin.github.com/type_index/index.html Peer review discussion detail: http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-library… My thanks to the Boost members whose peer review makes up this report: Robert Ramey, Vicente J. Botet Escriba, Gavin Lambert, Andrey Semashev, Steven Watanabe, pfultz2, Mathieu Champlon, Joël Lamotte Klaim, Rob Stewart, Jan Herrmann, Tony Van Eerd. Contents: · Summary of consensus from peer review ......................................................................................................... 1 · My recommendation to the library author and the Review Wizards ................................................................ 3 Summary of consensus from peer review: The consensus feedback was to accept TypeIndex after substantial modifications. There were two recommendations of rejection due to how substantial such modifications would need to be (i.e. a request for a second round of peer review with a new implementation). Note that my personal opinion based on post-review reflection is written in [square bracketed italics]. · Many seemed to feel that a boost::type_info’s member function API, where identically named to that of std::type_info member function API, ought to have identical compile-time effects. This implied that missing member function APIs, or other compile time errors for missing or incomplete functionality, would be okay but if name() returns some const char *, then any const char * so long as it meets the C++ standard is okay. [I think there are three use cases for a type_info like substitute: (i) as a lightest possible weight, non-RTTI requiring minimal type_info which can have any API it likes and ought to not be directly substitutable for std::type_info or std::type_index (ii) as a compile-time substitute for std::type_info in that it will compile without third party code modification, but may not produce reliable code due to not returning exactly the same values as std::type_info (iii) as a runtime substitute for std::type_info in that it will require code to be “ported” to it due to having a breaking API, but thereafter produces reliable code. I’ll be very blunt in saying that (ii) is a bad idea in my opinion, and (iii) is valuable but out of scope enhancement which could be added as a separate class after peer review. In my opinion, (i) is where we ought to focus, and I would recommend that the lightest possible weight type_info replacement be deliberately compile-time incompatible with std::type_info (where output is not identical to std::type_info) to force porting code to it so authors are not lazy.] · A large minority seemed to feel that a boost::type_info’s member function API, where identically named to that of std::type_info member function API, ought to have identical run-time outcomes. Most specifically, this would mean that member functions e.g. name() would return exactly what std::type_info’s name() does, even if for example name() returns a std::string instead of a const char * as would be necessary in pre-C++11 compilers. [This is really use case (iii) in the previous item.] · It was mentioned that it should be possible to optionally specialise std::hash<> for type_info for optional seamless use in hash taking containers. · Some felt that implementation-specific std::type_info quirks ought to be replicated. Others felt they should not, and a portable interface which works identically on all platforms is preferred. [This is really use case (iii) in the previous item.] · boost::type_info is currently initialised via a static cast from a std::type_info when RTTI is available. This is undefined behaviour, and some felt this to be a showstopper. I (Niall Douglas) looked into this more deeply due to its seriousness, and found that because most STL implementations define std::type_info with a virtual function table, the undefined behaviour static cast would cause dynamic_cast on a boost::type_info instance to misoperate. [I believe the RTTI induced misoperation to indeed be a showstopper, and that this use of undefined behaviour to reduce code bloat is an unsafe optimisation. A much lighter weight non-direct-substitute for std::type_info ought to be as code bloat parsimonious as is possible, while its lack of non-explicit interoperation ability with std::type_info ought to allow avoidance of needing any UB tricks.] · Some felt that any use of implied boost::type_info ought to be explicitly written as boost::type_info instead of relying on namespace lookup, as the name similarity to std::type_info may introduce confusion. [I agree] · It was mentioned that some function-local static data members are initialised in a thread unsafe way. [For information I have to hand a very lightweight BOOST_BEGIN_MEMORY_TRANSACTION() implementation ideal for this purpose. We could submit it to Boost.Detail and then everyone could use it?] · Magic macros such as __PRETTY_FUNCTION__ ought to not be referenced outside of a function as they don’t technically exist there. Checks for their existence ought to be within a function. · It was requested that a boost::type_id<> which takes some unknown variable instance as a parameter and therefore allows the compiler to deduce the type of the variable as the boost::type_index<T> type would be valuable. · A mechanism for programming compile-time logic with class inheritance trees such that inheritance can be determined at compile-time with RTTI disabled was requested. My recommendation to the library author and the Review Wizards: · In my opinion Antony ought to make TypeIndex v3 quite literally a very lightweight container of some unknown, but known to be uniquely identifying for some type, static const char * string. I think its class type and its list of member functions ought to be deliberately compile-time incompatible with std::type_info to force authors to upgrade their code. A conversion member function ought to be able to synthesise a corresponding std::type_info using typeid() from some boost::type_index<T>, but that’s about it. I would even, personally speaking, go so far as to only provide a boost::type_index and no corresponding boost::type_info, especially if the boost::type_id<T>() function can return a const boost::type_index<T>& and therefore can be used as a static const lref, or copy constructed from it etc. A suggested name() member function replacement which correctly breaks out the multiple confounding uses of std::type_info::name() into each of their three use cases (and which intentionally causes any use of name() to fail to compile) might be: Text Box: /*! Returns a static const char string of unknown format uniquelyidentifying this type.The only guarantee is that this string will beunique to the type within this process lifetime. */const char *unique_name() const noexcept;/*! Returns a representation of this type suitable for printing.This call may take some time as its storage may not be cached. */std::string pretty_name() const;class enum mangling{Native, //!< Whatever the native mangling used by this toolset isMSVC, //!< The Microsoft C++ mangling formatItanium //!< The Itanium C++ mangling format};/*! Returns the mangled form of the string representation of the type.After the calculation the value is cached statically such that the c_str()function can be used to convert the returned string to a const char *format identical to what may be returned by std::type_info::name() (orraw_name() on MSVC).This function may throw an exception if it does notsupport mangled type string calculation, including when mangling=Native onsome Bear in mind that user code can always subclass boost::type_index and add their own name() implementation based on one or more of the above new member functions. · In other words, here I think “less is more” in every way you look at it. I think a slimmer less heavy TypeIndex would be a superior solution. · I request the Review Wizards to allow Antony some time to make the changes to produce a v3 of the library, and then to allow TypeIndex v3 a Fast Track Review of five days to ensure the Boost community is happy and that its feedback has been incorporated. It was asked during peer review that such a five day period please include a weekend. I would be happy to serve as review manager again if requested. Niall Douglas Waterloo, Canada, November 2013

1 0

[boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
by Niall Douglas 12 Nov '13

12 Nov '13

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? 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!) Peer review ends on Thursday 21st Nov, ten days from today. Based on your feedback, at that point I will decide if I recommend TypeIndex for inclusion in my report to the review wizards. Comments can be posted to boost(a)lists.boost.org if you expect others to comment on your post, or to me privately if you wish your comment to not be made public. What is Boost.TypeIndex? TypeIndex performs three main functions: 1. It provides a consistent, well defined, portable boost::typeid() implementation with a consistent, well defined, portable boost::type_info class implementation which mirrors std::type_info. Implementation-specific weirdnesses (e.g. std::type_info::raw_name(), the fact the hash_code is often terrible and collides frequently) are abstracted out into a single, portable API. 2. It provides the ability to convert a type into a uniquely identifiable, container indexable, boost::type_info instance (e.g. &typeid(T) or C++11 class std::type_index) with RTTI disabled, thereby removing the need for requiring RTTI enabled for many type_info use cases. Any features which require RTTI are very clearly denominated in the API's name. 3. It allows the following Boost libraries to eliminate their dependency on RTTI which is a big win for embedded systems use, and it supplies patches for these libraries replacing RTTI std::type_info with boost::type_info. Feedback from the maintainers and users of these Boost libraries is *particularly* welcomed: Any, Graph, Property Map, Property Tree, Test, Variant, Xpressive I believe that TypeIndex meets the Boost library requirements at http://www.boost.org/development/requirements.html, and I have personally verified that it builds and passes all unit tests on GCC 4.6, clang 3.0 and MSVCs 10-12 [1]. I should add that Antony has already done three rounds of changes according to my feedback, and my thanks to him for being so dilligent and responsive. NOTE: Please read the TypeIndex documentation (linked to below) before asking any questions e.g. about potential code bloat etc. You'll probably find the answer already there. Source code: https://github.com/apolukhin/type_index/zipball/master Github: https://github.com/apolukhin/type_index Documentation: http://apolukhin.github.com/type_index/index.html Any questions about topics not in the documentation? Please do ask. [1]: A single unit test currently always is reported as failing to link correctly on MSVC. Antony believes this to be a bug in Windows bjam, as the Jamfile marks the link as expected to fail using link-fail but bjam does not respect this on Windows in this one use case scenario (yet weirdly the other expected link failures work fine!). Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost 1.55.0 released!
by Marshall Clow 11 Nov '13

11 Nov '13

Release 1.55.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains one new library and numerous enhancements and bug fixes for existing libraries. === New Libraries === • Predef: This library defines a set of compiler, architecture, operating system, library, and other version numbers from the information it can gather of C, C++, Objective C, and Objective C++ predefined macros or those defined in generally available headers, from Rene Rivera. === Known bugs with Visual Studio 2013/Visual C++ 12 === Visual Studio 2013 was released quite late in the release process, so there exist several unresolved issues. These include: • Serialization can't compile because of a missing include. • Using has_member_function_callable_with from Boost.Container's allocator_traits causes a compile error (#9332). • For several libraries overloads with intializer lists are incorrectly reported as ambiguous. This is a Visual C++ bug and it isn't clear if there's a good workaround. • In libraries such as Unordered and MultiIndex, calling overloaded functions with initializer lists can result in a compile error, with Visual C++ claiming that the overloads are ambiguous. This is a Visual C++ bug and it isn't clear if there's a good workaround. This won't affect code that doesn't use initializer lists, or uses an initializer list that doesn't require an implicit conversion (i.e. an initializer list of the container's exact value type). • Thread: ex_scoped_thread compile fails (#9333). For details, including download links, see http://www.boost.org/users/news/version_1.55.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.55.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Vladimir Prus Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

1 0