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: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2014-05-01 23:35:09

On 2014-05-01 13:02, 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:
>>> 2014-04-30 18:56 GMT+04:00 Andrey Semashev <andrey.semashev_at_[hidden]>:
>>>>
>>>> The ABI incompatibilities between release and debug (and different
>> flavors
>>>> of
>>>> debug in case of MSVC) libraries have caused a lot of grief already,
>> even
>>>> though Boost.Build tags debug and release binaries differently. Adding
>> yet
>>>> another source of incompatibilities certainly doesn't make things
>> better.
>>>>
>>>> Boost.Log has a compiled part. In some cases it needs to pass RTTI
>> between
>>>> the
>>>> compiled part an the user's application. If the application defines
>>>> BOOST_TYPE_INDEX_USER_TYPEINDEX then Boost.Log becomes broken. Hoping
>> that
>>>> the
>>>> user never does that is not what I'm prepared to do (because he will,
>> and
>>>> will
>>>> report a bug about weird crashes in Boost.Log). That is why I won't be
>>>> able to
>>>> use your library in Boost.Log.
>>>
>>> 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.

MSVC has #pragma detect_mismatch for this purpose (introduced in a
relatively recent version):

<http://msdn.microsoft.com/en-us/library/ee956429.aspx>

I don't know whether similar solutions are available in other compilers.

John Bytheway