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: Antony Polukhin (antoshkka_at_[hidden])
Date: 2014-05-02 02:23:00

2014-05-02 7:35 GMT+04:00 John Bytheway <jbytheway+boost_at_[hidden]>:

> 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.
>

Thanks a lot! Did not know about this feature.

Looks like Clang has the same pragma:
http://clang.llvm.org/doxygen/classclang_1_1PragmaDetectMismatchHandler.html

Though I have not found a clang version from which this feature is
supported.

-- 
Best regards,
Antony Polukhin