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

2013/8/28 Andrey Semashev

On Wed, Aug 28, 2013 at 12:56 PM, Antony Polukhin

...

wrote:

...

2013/8/28 Andrey Semashev

...

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.

May be I'm missing something, but this could be resolved in a following way. Instead of a separate basic_string_literal container: v.push_back(string_literal("Meow")); it is possible to make it a function: boost::string_ref string_literal(const char* v) { return boost::string_ref(v); } This won't require code change (no need to change `v.push_back(string_literal("Meow"));`) and uses already reviewed and accepted string_ref. You may also provide your own typedef for string_literal: template <class Char> struct only_literals_trait: char_traits<Char>{} typedef boost::basic_string_ref string_literal; typedef boost::basic_string_ref > wstring_literal; In theory (I did not check) this wont allow mixing string_refs to literals and string_refs to std::strings. 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.

Good point! I'll separate them.

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.

Also, when the review is planned?

I'm in search for a review manager. I was planning to search for a review manager more enthusiastically in the second half of September. If you're willing to become the review manager, I'll be pleased. -- Best regards, Antony Polukhin