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
> > 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_<
> >::type::type res_t;
And then use typeid(res_t)? Yes, that'd be ok, but it's better to do it like
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk