Re: [boost] [gsoc16] Can I quickly check if the below really is the best approach?

Subject: Re: [boost] [gsoc16] Can I quickly check if the below really is the best approach?
From: Lee Clagett (forum_at_[hidden])
Date: 2016-01-13 13:25:13

At Tue, 12 Jan 2016 20:09:02 -0000 Niall Douglas wrote:
> Dear Boost,
> 
> In the prototype https://svn.boost.org/trac/boost/wiki/SoC2016 at 
> https://goo.gl/1CQAuQ I claim "Even with all of Boost's facilities 
> [1] and using C++ 14, this program represents the currently best 
> available method of implementing a static constant associative map of 
> keys to values" and you can find either the code at the link or 
> pasted below.
> 
> Can I quickly check here if that claim is true? Is there a better way 
> than my example program?

AFAIK your code is the current best practice for generating a constant
static map with runtime lookups, unless there is some project hiding on
Github. If using external processes is an option, I've seen the entire
initialization at compile-time done by generating a static table using
Perl (or similar) to generate code. That solution works even when C is
a target language.

A constexpr map would be convenient in many use cases. I think the most
common case involves a string key, which has gotten me thinking about a
constexpr X3 symbol table (ternary tree). The one difficulty is getting
optimal efficiency in the static memory usage - I think this requires a
compile-time string (similar to metaparse). In the past I've used an
approach similar to yours with `spirit::symbols<>`, with the usual
downsides from dynamic (runtime) initialization.

> 
> [1]: I believe Boost.Hana could implement a static constan 
> associative map quite easily, but I'd be fairly sure Hana will likely 
> be beyond most students.
> 

If using Hana is beyond most GSoC students, it seems like writing a
`constexpr` associative map will be too. For example, computing the
amount of storage space needed for the map must be done _before_
entering the constexpr function in its return type, which I think is
harder to grasp than the purely runtime components of Hana. And if the
student can understand that level of TMP, then Hana should not be an
issue.

> #define STRING_VIEW(str) { str, sizeof(str)-1 }
> constexpr std::initializer_list<std::pair<const string_view, 
> weekday>> string_to_weekday {
>     { STRING_VIEW("sunday"),    weekday::sunday },
>     { STRING_VIEW("monday"),    weekday::monday },
>     { STRING_VIEW("tuesday"),   weekday::tuesday },
>     { STRING_VIEW("wednesday"), weekday::wednesday },
>     { STRING_VIEW("thursday"),  weekday::thursday },
>     { STRING_VIEW("friday"),    weekday::friday },
>     { STRING_VIEW("saturday"),  weekday::saturday }
> };
> 

The macro `STRING_VIEW` seems unnecessary because the `string_view`
constructor taking a single NULL-terminated string is also
`constexpr`. Although, it could reduce the amount of computation
done by the C++ interpreter in the compiler.

Lee