Re: [boost] [utility] Proposal to extract some components from Boost.Log

Subject: Re: [boost] [utility] Proposal to extract some components from Boost.Log
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-09-09 03:04:43

On Wed, Aug 28, 2013 at 4:16 PM, Antony Polukhin <antoshkka_at_[hidden]>wrote:

> 2013/8/28 Andrey Semashev <andrey.semashev_at_[hidden]>
>
> > > > One question: you're using strcmp to compare type_info names on some
> > > > compilers to solve problems with cross-library comparisons. If symbol
> > > > visibility is configured properly, cross-library comparisons should
> > work
> > > > properly, shouldn't they? Or are you aware of platforms that do not
> > > support
> > > > cross-library comparisons at all? I'm asking because the list of such
> > > > faulty platforms in your code looks overly long. E.g. on Linux
> > type_info
> > > > can be compared just fine, as long as the type info symbols have
> > default
> > > > visibility, and the comparison is faster than strcmp.
> > >
> > > GCC's Standard library and some other libraries had an issue. They were
> > > assuming that if two dynamic libraries have same strings, then dynamic
> > > linker will load those symbols to the same address. That's why they
> were
> > > comparing types by pointers to type names instead of comparing type
> > names.
> > > Unfortunately assumption is not right for some platforms (ARM) and
> > linkers.
> >
> > Can these particular configurations be detected at compile time? E.g. by
> > testing for ARM target? Comparing symbol addresses works on x86 Linux,
> and
> > I'd like to use it.
> >
>
> Oh yes, I'll need to check GCC once more. As I remember that issue was
> fixed in GCC 4.5 and it is safe to use default std::type_info comparison.
>

I have a suggestion about type_info_wrapper. How about I extract it from
Boost.Log and then you add no-RTTI and strcmp workarounds to it? This way
it will become equivalent to your type_index.