Re: [boost] Static constexpr map (was: Re: [gsoc16] Can I quickly check if the below really is the best approach?)

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
> http://www.nedproductions.biz/
> http://ie.linkedin.com/in/nialldouglas/
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost