How to implement a constant-expression counter in C++

How to implement a constant-expression counter in C++(b.atch.se)

46 points by refp 11 years ago | 11 comments

refp 11 years ago |

This is the second post in the series regarding "non-constant constant-expressions in C++" - http://b.atch.se/posts/non-constant-constant-expressions/

Feedback is more than welcome!

/Filip Roséen

Leszek 11 years ago | |

Do you consider this a C++ language bug that you happen to be able to exploit? Or a necessary result of being able to combine several correctly behaving features?

refp 11 years ago | | |

It is part of both, the technique described is not the only way to reach a solution for the given problem (implementing a counter usable in constant-expressions).

In other words; if one sees this as a "bug" in the ISO C++ Standard, the "problem" is a lot deeper than friendly definitions (the technique used in the post).

C++ is a complex language, where many rules touch upon other, and with that it is not surprising that some rules can be bent to allow behavior which was perhaps never intended.

Future posts (probably after part 3) will address the philosophy of the "exploit", other techniques that boil down to doing the same thing, as well as proposed (ISO Standard) wording to "fix" the "problem" - if that is the path being walked.

Chris_Newton 11 years ago |

This is both ingenious and terrifying...

The underlying “paradox” seems to be that a constexpr is in spirit a compile-time constant, that testing whether certain things are defined is possible using such an expression, but that in C++ whether those things have in fact been defined yet changes during the course of compilation.

So, if you can control exactly when things become defined, for example by using clever template instantiation mechanics as shown here, you can potentially change the value of a constexpr during the course of compilation.

I could see this having some entertaining and perhaps useful possibilities for people who enjoy things like template metaprogramming. On the other hand, the robustness of the technique does seem to depend on being able to very tightly control those instantiation mechanics, which is a minefield already in C++, which I suspect makes this technique a little too clever for production use.

[Edit: Removed reference to this technique being like embedding a compile-time linear type system. That doesn’t seem to be quite the right analogy here; it’s more a system where you can generate unique new values but never return to values you had before once they have changed.]

BudVVeezer 11 years ago |

This topic was discussed in Lenexa at last week's C++ standards meeting, and the direction the core working group was thinking was that this should be ill-formed, but is currently under specified. I would not rely on this ADL constexpr trick working for long (at least until CWG has had the chance to really pick apart the issue and change the wording to explicitly allow it).

refp 11 years ago | |

I have been trying _very_ hard to get in contact with the folks that are discussing this approach; just preventing ADL constexpr tricks (through "friendly definitions") isn't enough.

I am still waiting for the relevant parties to reply to my emails, but an article explaining "everything" (and the different approaches (about 3 at the current time, in addition to "friendly definitions") will be published soon.

There is a lot of wording that has to be changed in order to prevent the semantics explained.

BudVVeezer 11 years ago | | |

I apologize for being imprecise. We're aware it's more than just ADL or constexpr, but we had insufficient time to address it at this meeting. It's definitely on our radar, we flagged it as a high priority item.

beeforpork 11 years ago |

This is absolutely insane. In the best possible sense of that word. I've always known I will never know C++ properly, as it is such a complex language. (Too complex I think.) I learned a few things from your insane stories. Thank you! Looking forward to being amazed more.