Boost logo

Boost :

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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at