Re: [boost] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th

Subject: Re: [boost] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-05-01 13:54:43

On Thursday 01 May 2014 21:02:14 Antony Polukhin wrote:
> 2014-05-01 13:07 GMT+04:00 Andrey Semashev <andrey.semashev_at_[hidden]>:
> > On Wednesday 30 April 2014 19:40:54 Antony Polukhin wrote:
> > > 
> > > I see your point. Let's try to resolve this somehow without throwing
> > > away
> > > the BOOST_TYPE_INDEX_USER_TYPEINDEX macro.
> > > 
> > > Is in your case type_index one of the function arguments? If yes - then
> > > user won't be able to link modules with and without
> > > BOOST_TYPE_INDEX_USER_TYPEINDEX. Linker won't find functions.
> > 
> > Currently, in some cases std::type_info is the argument. If type_index is
> > the
> > argument in those cases, linker errors will protect from crashes in run
> > time.
> > But these functions are not always used by the application, so it's not a
> > 100%
> > protection.
> > 
> > In other cases std::type_info const* is stored in structures and
> > containers
> > thereof, and do not affect mangled type and function names. I'll have to
> > inspect the code to see if Boost.Log actually has these cases but it
> > certainly
> > does not prohibit them; they may appear in user's code as well.
> > 
> > I know there are workarounds for this. Like add yet another tag to
> > Boost.Log
> > internal namespace. (BTW, using a function is not really a good solution
> > because this function needs to be called in many places of the code; it
> > reduces efficiency, introduces false dependency on the binary, and is easy
> > to
> > miss). But these are workarounds that are not needed now and required to
> > support a controversial feature. With Boost.Log's internal namespace the
> > workaround may seem easy to implement, but other libraries don't have such
> > a
> > namespace, and there the fix would not be so easy.
> 
> Can we make somehow such link-time assertion in TypeIndex library itself
> (extern variable, function...)? I have no good ideas right now,  but I'm
> almost certain that it is possible.

I honestly can't think of one, unless Boost.TypeIndex has a compiled part, 
which I think is not acceptable. Another solution would be to mangle boost 
namespace name but that is hardly doable since this would affect all 
libraries.

> > In that header, I can see the code that works around the problem by using
> > template specializations. As I understand, the compiler matches
> > specializations for int when the template is instantiated for signed int.
> > Why
> > not make the same workaround in Boost.TypeIndex? The case is very much the
> > same.
> 
> I do not have any will to add many overloads to fix an antique compiler
> that even can not be tested.
> How about a following workaround for those compilers:
> 
> typename boost::mpl::if_<
>     boost::is_signed<no_cvr_t>,
>     boost::make_signed<no_cvr_t>,
>     boost::mpl::identity<no_cvr_t>
> 
> >::type::type res_t;

And then use typeid(res_t)? Yes, that'd be ok, but it's better to do it like 
this:

  typename mpl::eval_if<
    mpl::and_<
      is_integral<no_cvr_t>,
      is_signed<no_cvr_t>
    >,
    make_signed<no_cvr_t>,
    mpl::identity<no_cvr_t>
  >::type res_t;

At least MSVC 7.1 has problems applying is_signed to non-integral types, not 
sure about those EDG compilers, but it's better to be on the safe side.

Of course that code is only needed for the old EDG compilers.