Subject: Re: [boost] Compile Time String in C++14
From: Mikael Persson (mikael.s.persson_at_[hidden])
Date: 2014-08-26 20:24:27
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?
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":
Which is very similar (and better explained) to Andrzej Krzemienski's
Or Sprout's very comprehensive implementation (basically a compile-time
implementation of std::string):
Or yet again, my own more light-weight version which supports compile-time
concatenation, hashing and int-to-string functions only:
which I explain in more details here (warning: it's a bit more of a
tutorial for beginners, not aimed at experts):
> 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.
Compile-time strings are not a new thing, they are simply not very
practical because they cause so much compilation overhead (because of
compile-time char-by-char operations, deep compile-time recursions, and
costly template instantiations), IMHO.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk