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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-01-17 16:51:06

On 14 Jan 2016 at 13:02, Gottlob Frege wrote:

I had a crack this weekend at a toy static_map to see if I could 
improve on Louis' toy solution from 
https://gist.github.com/ldionne/f7ff609f00dc7025a213. I learned many 
very interesting things.

> Possibly due to limitations with pre-11 C++, I had a two-step process
> for declaring/defining the map:

It turns out this restriction remains in C++ 14, and currently C++ 
17. The problem is that nested braced init of heterogeneous types is 
basically only possible via a C array, so either you do this:

constexpr std::pair<int, const char *> map_data[] = {
  { 5, "apple" },
  { 8, "pear" },
  { 0, "banana" }
};
constexpr auto cmap = make_static_map(map_data);

... or you do as Louis did:

constexpr auto cmap = make_static_map(
  std::make_pair(5, "apple"),
  std::make_pair(8, "pear"),
  std::make_pair(0, "banana")
);

I personally think the first form looks nicer. If C++ 17 could gain 
the ability to convert nested braced init sequences of heterogeneous 
types in a set of nested std::make_tuple()'s, I think that would be a 
great language addition for C++ 17.

> Constexpr probably gets rid of many of those problems.

Unfortunately, constexpr as currently implemented by at least clang 
3.7 and VS2015 is lazy not greedy, so currently even if all the 
inputs to a constexpr expression are constexpr but the returned value 
is not stored constexpr, right now the expression is not executed 
constexpr by any major compiler. In code:

  // No output in assembler, so constexpr except on GCC 5.3
  constexpr auto cmap = make_static_map(map_data);

  // No abort() appears in assembler except on GCC 5.3, so this
  // was executed constexpr
  if(!cmap[8]) abort();

  // This however does cause code implementing a lookup to be 
generated
  // on all compilers, so this was NOT executed constexpr. The cause 
is
  // storing the result in a non-constexpr variable.
  const char *foo=cmap[5];

If you'd like to play with this yourselves, see 
https://goo.gl/eO7ooa.

I was not aware of that constexpr is currently implemented lazy not 
greedy before, and I still find it a highly surprising choice to not 
avail of an optimisation. GCC is particularly conservative in not 
making use of constexpr execution at all, even VS2015 matches clang 
3.7.

Note that the C++ standard, in so far as I can tell, gives compiler 
implementors the choice of what to do if the results from a constant 
expression are not used in a constant expression - they can either 
execute constexpr, or not. I therefore assume the compiler vendors 
have good reasons for choosing to generate code when the standard 
says they don't have to.

Niall

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