Re: [boost] Compile Time String in C++14

Subject: Re: [boost] Compile Time String in C++14
From: Mikael Persson (mikael.s.persson_at_[hidden])
Date: 2014-08-27 01:37:32

> I think Abel needs the value encoded in the type

Ok. Now I get it. That was the critical piece of information I did not get
from the previous communications. Thanks for clearing that up.

I think that the term "compile-time string" led to the confusion, because
there is already a pretty good tradition of compile-time string
construction and manipulation. In the sense that it pre-computes or
pre-parses strings during compilation. The idea of computing types out of
compile-time strings is a different problem altogether. And I would not
call this "compile-time strings", I would call them "meta-programming
strings", because that's what they are, strings used to construct types
(i.e., meta-programming). The terms used completely threw me off there.

> I can't see a straightforward way to pass such constexpr string as a
template parameter and do something reasonable with it internally.

Yeah, sorry, my bad. I completely missed that point somehow. I guess the
"metafunction" should have been a hint, but I guess it must be getting
late. You're right, the barrier to cross from constexpr to template
parameters is pretty much impenetrable as far as strings are concerned
(btw, you can easily use a constexpr string to generate a unique hash that
can be used to construct a type that is unique to the original string, but
I guess that's not quite what you are looking for). So yeah, you're right,
you cannot do that with compile-time strings.

> 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.

Ok, I see, you want to remain purely TMP the whole way, and the end-goal of
your expressions are types, not strings. (BTW, if your goal is compile-time
string parsing, then you ought to be using constexpr strings, not TMP
strings, because as much overhead as there is when using constexpr for this
kind of work, I would imagine the overhead of using TMP for this would be
astronomical, intractable)

In that perspective, I can totally see how your MACRO might make sense, if
it was legal. The trick really is to circumvent the standard rules that
essentially make it impossible to map a string literal into a template
parameter pack of chars. I think that with your use of the lambda
expression, you tried to cheat your way out of those rules, but there is a
specific rule for that loophole, $5.1.2/2:
"A lambda expression shall not appear in an unevaluated operand"
This means that you cannot try to smuggle a string literal out of an
unevaluated lambda in order to get it into a type. And the rationale for
this rule is specifically aimed at avoiding opening the can of worms that
it would be if people were allowed to do meta-programming from lambda's,
because you could hide all sorts of monstrous things in a lambda and then
pull them out into templates.

That pretty much closes off your proposed avenue, doesn't it? If you got
this to work, I would have to imagine it is due to working with a
non-compliant compiler.

I tried your code with both clang 3.5 and GCC 4.8.2, and they both reject
it on the grounds of the rule that I just stated.

You'll have to find another way to do this. It is a tough problem. And when
it comes to working with string literals, I'm afraid the pre-processor is
pretty much all you have, as Abel evidently realized when creating the
MPLLIBS_STRING macro.

I personally find this problem very frustrating because we all know that
all compilers could do a lot more work with strings at compile-time, either
as constexpr or as template parameters. And we wouldn't have to resort to
such ridiculous and inefficient solutions as macro expansions or template
instantiations with packs of chars.

Sorry again for my initial misunderstanding of your aim with the code you
showed.

Cheers,
Mikael Persson