Le 20 janvier 2012 00:35, Howard Hinnant <[email protected]> a écrit :
> 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 > > > Thanks Howard for the reference. I would have gone for a slightly different proposal (giving an exhaustive list of the C functions that should be so tagged) as the current proposal seems to create some non-portable situations (unless you wrap all such functions in functions of your own and resort to the SFINAE trick exposed by Richard). I am also a bit sad that the last activity on this issue is recorded as being nearly a year ago. Is there a way to bump issues ? -- Matthieu
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
