Re: [boost] [metaparse] performance comparisons?

Subject: Re: [boost] [metaparse] performance comparisons?
From: Roland Bock (rbock_at_[hidden])
Date: 2015-06-07 12:17:39

On 2015-06-07 11:07, Roland Bock wrote:
> On 2015-06-01 18:06, Peter Dimov wrote:
>> Abel,
>>
>> After looking at Metaparse, I inquired on the c++std-ext list as to
>> whether user-defined operators can create char packs from integer or
>> floating point literals, but not from string literals, as this would
>> have made the MPLLIBS_STRING macro unnecessary.
>>
>> As it turns out, there has been such a proposal, N3599:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3599.html
>>
>> later referenced by two competing proposals for compile-time string
>> literals, N4121 and N4236:
>>
>> https://isocpp.org/files/papers/n4121.pdf
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4236.html
>>
>> N3599 has been however rejected, as the committee apparently feels
>> that representing compile-time strings as char packs is inefficient
>> and impractical, and prefers constexpr char arrays.
> FWIW, sqlpp11 also uses char packs to represent and being able to
> compare strings at runtime. It is used like this (full example is
> attached, requires c++14, won't work with current MSVC-2015RC):
>
> struct A
> {
>   static constexpr const char _literal[] = "delta";
>   using name_t = sqlpp::make_char_sequence<sizeof(_literal), _literal>;
> };
>
> static_assert(
>     std::is_same<A::name_t,
>                  sqlpp::char_sequence<'d', 'e', 'l', 't', 'a',
> '\000'>>::value,
>     "");
>
> However, this is limited in the way that the type cannot be based on a
> literal outside a struct/class. There also is a macro that can be
> employed to create such types, e.g:
>
> SQLPP_ALIAS_PROVIDER(hello);
>
> static_assert(
>     std::is_same<hello_t::_alias_t,
>                  sqlpp::char_sequence<'h', 'e', 'l', 'l', 'o',
> '\000'>>::value,
>     "");
>
>
> The MACRO cannot be called in a function, though, since local classes
> must not have static members.
>
>
> Thus, while I assume that it is faster than what happens inside the
> MPLLIBS_STRING (haven't measured it), its use is more limited, too.
>
>
> Best,
>
> Roland
Sorry, I experimented with the file before sending it and corrupted it.
The attached version actually compiles...