Boost logo

Boost :

Subject: Re: [boost] Static constexpr map (was: Re: [gsoc16] Can I quickly check if the below really is the best approach?)
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2016-01-14 13:02:07

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_at_[hidden]> 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
> _______________________________________________
> Unsubscribe & other changes:

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