Re: [boost] [gsoc16] Can I quickly check if the below really is the best approach?

Subject: Re: [boost] [gsoc16] Can I quickly check if the below really is the best approach?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-01-13 06:57:25

On 12 Jan 2016 at 13:55, Steven Watanabe wrote:

> > Can I quickly check here if that claim is true? Is there a better way 
> > than my example program?
> > [snip]
> 
> If malloc is your biggest concern, try boost::container::flat_map.

Sorry, the problem being solved was likely poorly specified by me.

What the project idea is for is a boost::[container::]static_map<Key, 
T> which:

1. Like std::array<T, N>, it is a fixed size after construction.

2. Like std::array<T, N>, all member functions are constexpr, thus 
allowing constexpr use where Key and T allow that.

3. Keys or the number of items cannot be modified, but values can be.

4. The primary use case example is something like this:

// At global scope, allocates no memory whatsoever
static const constexpr static_map<int, const char *> map {
  { 5, "apple" },
  { 8, "pear" },
  { 0, "banana" },
  ...
};
// Works, constexpr "apple"
constexpr const char *what_is_5 = map[5];
// Works
assert(map[5] && !strcmp(map[5], "apple");
// Works
map[5]="orange";
assert(map[5] && !strcmp(map[5], "orange");
// Throws exception as there is no key 6
map[6];
map.at(6);

Does this make more sense? I know this may seem to be too trivially 
easy to be worth adding to Boost, but if you've ever seen code where 
people embed large automatically generated data sets into C arrays 
and then do linear lookups, the proposed static_map is *exactly* for 
that use case - and ~O(1) lookup complexity to boot.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/