Re: [boost] [metaparse] performance comparisons?

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

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