On Thu, January 19, 2012 16:52, Jonathan Sauer wrote: >>> 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.
We can support __builtin_* in constant expressions as a conforming extension; this is already how we behave for all the __builtin_*s providing C library functions which we can constant-fold (namely, __builtin_strlen, __builtin_huge_val*, __builtin_inf*, __builtin_nan*, __builtin_fabs* and __builtin_copysign*). If you want to add more such builtins to this list, the first step is to implement the corresponding operation for llvm::APFloat. Support in clang should then be trivial to add -- it'd also be great to add constant folding to llvm for such cases. Constant-folding (non-__builtin_)strlen can theoretically break conforming code and is likely to lead to people accidentally writing non-portable code in practice, and I've not found a clause in C++11 allowing the implementation to mark more functions in the library as constexpr, so I'm reluctant to support it. If you want to be non-portable, use __builtin_strlen. - Richard _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
