$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.