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