On Jan 19, 2012, at 6:28 PM, Howard Hinnant wrote: > On Jan 19, 2012, at 5:55 PM, Richard Smith wrote: > >> On Thu, January 19, 2012 19:56, Howard Hinnant wrote: >>> On Jan 19, 2012, at 2:30 PM, Matthieu Monrocq wrote: >>>> Le 19 janvier 2012 17:52, Jonathan Sauer <[email protected]> a écrit : >>>>>> Do you know if the same apply (I would guess so) to std::strlen ? >>>>>> >>>>>> >>>>>> It seems a pity that such a trivial function could not be constexpr as >>>>>> making it constexpr is actually dead simple. I wonder if it would be >>>>>> worth a Defect Report. >>>>>> >>>>> This would seem very reasonable to me... >>>>> >>>> >>>> As well as a lot (all?) of the math functions in cmath. And clang's >>>> built-ins (__builtin_sin etc), too. >>>> >>>> >>>> What do you think? >>>> Jonathan >>>> >>>> >>>> I haven't followed the C11 proposal, is the "constexpr" idea addressed >>>> there or would it be a specific C++ issue ? >>>> >>>> C++ imports a massive amount of C functions, and keeping their signature >>>> as-is will be a hindrance, I don't fancy the idea of recoding them all in >>>> pure C++ to allow such optimizations! It seems like at least the `std::` >>>> versions could be made `constexpr` when possible. >>>> >>>> I am putting Howard in copy since this seems something libc++ would be >>>> interested in, and perhaps his C++ committee experience could help us here. >>>> >>>> >>>> -- Matthieu >>>> >>> >>> I have not come up to speed on constexpr. However, I do know that if it is >>> the case that no conforming program could detect (or behave differently -- >>> besides performance) if the constexpr is added to a C function, then it >>> should be ok. >> >> It is not the case; whether an expression is a constant expression can be >> detected in a SFINAE context: >> >> >> template<typename T> T declval(); >> >> template<typename T, T V> struct Value { >> constexpr static T value = value; >> }; >> >> template<typename F, F f, >> typename ...A, A ...a, >> int = (f(a...), 0)> >> constexpr bool isConstexpr(Value<F, f> fn, Value<A, a> ...args) { return >> true; } >> >> template<typename ...T> >> constexpr bool isConstexpr(...) { return false; } >> >> int f(int); >> constexpr int g(int n) { return n; } >> >> #define VALUE(x) Value<decltype(x), x>() >> constexpr bool test1 = isConstexpr(VALUE(&f), VALUE(0)); >> constexpr bool test2 = isConstexpr(VALUE(&g), VALUE(0)); >> static_assert(!test1, ""); >> static_assert(test2, ""); > > Like I said about not being up the learning curve on constexpr. ;-) > > In this case, if the LWG wants to allow this, we'll need some Chapter 17 > verbage to allow it. > > I recommend someone more educated on constexpr than myself open an issue on > this. The directions for opening an LWG issue are here: > > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue > > If anyone needs help on how to get an issue opened, I *am* an expert on that, > so please let me know. I can assure you that this issue will be taken > seriously on the LWG.
Never mind, the issue has already been opened: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2013 Howard _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
