I've experimented with static_map quite a bit. But never with C++11/14, unfortunately. Some thoughts: - once you have static_map<A,B>, the next thing you immediately want is bi_map<A,B> - to offer two way lookup. - and from there, you want multiple keys and columns: <A,B,C> - and maybe projection functions as well: <A,B,C, key(B)> I'm not sure, however, what the usage looks like for the bimap and multimap cases. It is no longer the simple syntax of mapvar[a] = b; - I had static_map<A, B> was not copyable, but static_map<A, const B> was copyable (but didn't actually do a copy, since it is immutable - just stored a reference). Not really sure about the benefit of that design decision, however. Possibly due to limitations with pre-11 C++, I had a two-step process for declaring/defining the map: // the map is this type typedef static_map<A,B> ab_map; // but the data/table is an array of this type: // using the inner element_type means you don't repeat A,B (more robust to changes) static ab_map::table_entry_type ab_table[] = { { a1, b1 }, { a2, b2 }, ... }; // the actual map: ab_map theMap = ab_table; // constructor does magic Doing a bi-map is fairly easy above, as table_entry_type can actually be { A, B, reverse_index } but the { a1, b1 } initialization is still valid as the reverse_index gets initialized to 0. The reverse_index is basically an extra hidden column. Constexpr probably gets rid of many of those problems. On Wed, Jan 13, 2016 at 2:43 PM, Niall Douglas <s_sourceforge@nedprod.com> wrote:
On 13 Jan 2016 at 13:25, Lee Clagett wrote:
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
Cool, thanks for having a look.
[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.
All absolutely true, but you're forgetting the time it takes to master a Boost library and a Boost/STL idiomatic practice. As a general rule, if they are extending a Boost library they just about get going by the end of the summer after a lot of help, whereas if it's new code you tend to see more get accomplished because they are more psychologically invested for them to build their own thing rather than build atop someone else's thing (despite that the latter is almost certainly better for them in terms of training).
#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.
Sadly, the current proposal for string_view does not provide a default Traits length function which is constexpr for const char *. Yes, I find that very daft as a default design choice for a string_view, but the macro at least makes it not too irritating.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost