Boost logo

Boost :

Subject: Re: [boost] Compile Time String in C++14
From: TONGARI J (tongari95_at_[hidden])
Date: 2014-08-26 21:51:18


2014-08-27 8:24 GMT+08:00 Mikael Persson <mikael.s.persson_at_[hidden]>:

> I also fail to see the advantage of this implementation. I mean, it still
> uses index_sequence (or, in the first version, a variadic template
> parameter pack of chars), which is the main problem with using compile-time
> strings; it's the common problem in most real constexpr string
> implementations, as far I as know. An implementation of a constexpr string
> class that would avoid forming this type of very costly (non-scalable)
> template instantiation is starting to become interesting from a usability
> point of view, but short of that, it's hard to justify using it for
> anything but trivial tasks. That was just a remark.
>
> And as Paul remarks, you have obviously omitted the "constexpr" specifier
> in many places.
>
> So, can you explain how your implementation differs or improves upon
> existing constexpr string implementations?
>

My intention was to implement a compile-time Spirit that operates on CT
string and returns different types depending on the input, so my usage is a
bit different.
Unlike the way Abel used in his metaparse, where every thing is a template
parameter, as `metafunction_expecting_a_string<decltype(LIT("Hello"))>`,
I'd like use `string(LIT("Hello"))`, which I think is more like the way
Boost.Hana adopts.

I don't think constexpr is needed in my case, because what I need is the
type (i.e. the constants encoded in the type), not the value.
For example, here's how I implement the string_parser:

```c++
struct string_parser : parser<string_parser>
{
    template<class S>
    struct parse_impl;

    template<char... cs>
    struct parse_impl<str<cs...>>
    {
        template<char... etc>
        static auto apply(str<cs..., etc...>)
        {
            return success(str<etc...>(), str<cs...>());
        }

        template<class S>
        static auto apply(S s)
        {
            return fail(s);
        }
    };

    template<class S, class Str>
    static auto parse(S s, Str)
    {
        return parse_impl<Str>::apply(s);
    }
};

constexpr string_parser string = {};
```

which can then be used:

```
string(LIT("123")).parse(LIT("1234")); // returns (true_, str<'4'>,
str<'1', '2', '3'>), a pack of (result, rest-input, attr)
```

> Here is a short list of existing compile-time string implementations (in
> case some people reading this are not familiar with the options available
> to solve that problem):
>
> Scott Schurr's very simple demo of "str_const":
>
> https://github.com/boostcon/cppnow_presentations_2012/blob/master/wed/schurr_cpp11_tools_for_class_authors.pdf?raw=true
>
> Which is very similar (and better explained) to Andrzej Krzemienski's
> "StrWrap":
>
> http://akrzemi1.wordpress.com/2011/05/11/parsing-strings-at-compile-time-part-i/
>
> Or Sprout's very comprehensive implementation (basically a compile-time
> implementation of std::string):
>
> https://github.com/bolero-MURAKAMI/Sprout/blob/master/sprout/string/string.hpp
>
> Or yet again, my own more light-weight version which supports compile-time
> concatenation, hashing and int-to-string functions only:
>
> https://github.com/mikael-s-persson/ReaK/blob/pp_dev/src/ReaK/core/base/cnst_string.hpp
>
> which I explain in more details here (warning: it's a bit more of a
> tutorial for beginners, not aimed at experts):
>
> https://www.daniweb.com/software-development/cpp/code/482276/c11-compile-time-string-concatenation-with-constexpr

Thanks for the information, I know some of them, will check out later.

> @ Abel:
>
> > So the way I'd use it would be something like:
> > ...
> > Did you manage to use these strings as template arguments somehow?
>
> AFAIK, you can use any of the above-listed implementations of constexpr
> strings in the way that you showed, but not the one discussed here.
>

I think Abel needs the value encoded in the type, so something like
Sprout's string may not help.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk