|
Boost : |
Subject: Re: [boost] compile time parser generator
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-01-08 21:08:12
on Sun Jan 08 2012, "Simonson, Lucanus J" <lucanus.j.simonson-AT-intel.com> wrote:
> From: Of John Bytheway
>
>>>> Literals can be extended in both raw and cooked forms, with the
>>>> exception of string literals, which can only be processed in cooked
>>>> form. This exception is due to the fact that strings have prefixes
>>>> that affect the specific meaning and type of the characters in
>>>> question.' - source: wikipedia -
>>>> http://en.wikipedia.org/wiki/C%2B%2B11#User-defined_literals .
>>> Right below that Wikipedia describes a variadic template-based
>>> mechanism, where the compiler instantiates a template operator and
>>> passes the characters as template arguments to it. The return type of
>>> that operator could be an MPL list of boxed characters and we could
>>> access it using decltype - at least this is the idea.
>>That interface is only available for integer and floating-point
>>literals, not string literals (which that page also says). The only way
>>to get at characters of a string literal at compile time is through
>>constexpr functions.
>
> So the question is, is there any way to get from a literal string to
> an MPL list of literal char for each character.
Nope.
> From there it is just simple metaprogramming to do whatever with the
> string. It seems the constexper approach promises this, but I'd like
> to see the code example for what it looks like to use it and also how
> it works.
constexpr is somewhat crippled: although a constexpr function executes
at compile-time, it has to obey the same rules as any other function.
For example, its return type can depend on the type, but never on the
*value*, of its arguments, and once you're inside the function, the
contents of the argument are not treated as compile-time constants.
So, I think constexpr actually doesn't promise it.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk