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, https://goo.gl/eO7ooa https://goo.gl/eO7ooa, 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 https://svn.boost.org/trac/boost/wiki/SoC2016 for a recently expanded project idea description. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/