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

On 2014-05-01 13:02, Antony Polukhin wrote:

2014-05-01 13:07 GMT+04:00 Andrey Semashev :

...

...

2014-04-30 18:56 GMT+04:00 Andrey Semashev :

...

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

On Wednesday 30 April 2014 19:40:54 Antony Polukhin wrote: 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