Boost logo

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