[cfe-commits] r148374 - in /cfe/trunk: lib/AST/ExprConstant.cpp test/SemaCXX/constexpr-strlen.cpp

[Matthieu Monrocq]

Le 20 janvier 2012 00:35, Howard Hinnant <hhinnant at apple.com> 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 <jonathan.sauer at gmx.de> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120120/5c327791/attachment.html>