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-08-28 05:32:38

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

> 2013/8/28 Andrey Semashev <andrey.semashev_at_[hidden]>
>
> > 2. basic_string_literal< CharT, CharTraitsT > class template.
> >
> <...>
>
> Could you please describe the difference between this class and string_ref
> in more details? Why can't you use string_ref instead of
> basic_string_literal?
>

I use basic_string_literal when I need to be sure the string is a literal.
This gives the guarantee that the string won't disappear or change all of a
sudden, which allows to safely store string_literals in containers, etc. In
Boost.Log string_literals are used to maintain the list of scopes (which
have scope names and source file names as literals), and the mentioned
guarantee allows to avoid copying the strings in most cases.

3. type_info_wrapper class.
> >
> <...>
>
> Nice thing, but I'd rather wait for review of more functional
> https://github.com/apolukhin/type_index library and include that library
> into utility.
>

Interesting, although I'd like type_index and template_index to be
separated. My type_info_wrapper is close to your type_index, so if I had to
port to your library I wouldn't want any additional unneeded code to be
included.

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.

Also, when the review is planned?

> 4. empty_deleter class.
> >
> <...>
>
> May be it is better to move that into Boost.SmartPtr library?
>

I don't know, may be. boost::checked_deleter is not in Boost.SmartPtr and
is not only used with pointers. My usage of empty_deleter was with pointers
so far, but who knows?..

> > 5. BOOST_LOG_UNIQUE_IDENTIFIER_NAME(prefix) macro.
> >
> <...>
>
> Boost.PP is a better place for that macro. I'd like to have it, but I'm not
> sure that `prefix ## __LINE__` is enough for some cases.
>

Maybe. The macro worked just fine for my cases so far, but I'm not
insisting.