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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-01-19 06:23:56

On 18 Jan 2016 at 21:17, Shangtong Zhang wrote:

> > If it is constexpr, it can only be modified
> > in a constexpr evaluation context, and otherwise not.
> When a variable is declared as constexpr, it seems it’s also const,
> constexpr int foo() {
> constexpr int i = 5;
> i = 6;
> return i;
> }
> int main () {
> constexpr int j = foo();
> return 0;
> }
> foo is a constexpr evaluation context, but modification of i in it will still leads to compile error.

I admit surprise the code above is disallowed, but I haven't studied
the text of the C++ 14 ISO standard like I did the C++ 11 standard.

What definitely does work in C++ 14 is that non-const constexpr
member functions are allowed to mutate *this, and I've made extensive
use of this in my own code.

> > • Values, though not keys nor number of items, are modifiable.
> So I think this feature is also challenging.
> In your crack, <>,
> if I add
> cmap[0] = “orange”;
> in main function, it will leads to compile error.

Correct, because cmap has constexpr storage.

I meant that if and only if you store the static map into a
non-constexpr variable (like the "map" variable in my code example),
values become mutable but key-lookup-to-value remains constexpr. In
other words, the implementation becomes 100% constexpr when the map
is stored constexpr, but only key lookup to value is 100% constexpr
when the map is not stored constexpr.

This part is the challenging part, and what makes this GSoC project
idea non-trivial to implement. This is why a successful candidate for
this project idea will need excellent constexpr programming skills.

See for a recently
expanded project idea description.


ned Productions Limited Consulting

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