On Fri, Oct 19, 2012 at 10:53 PM, Chandler Carruth <chandl...@google.com> wrote:
>
> On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith <rich...@metafoo.co.uk>
> wrote:
> >
> > [Crossposted to both GCC and Clang dev lists]
> >
> > Hi,
> >
> > One issue facing library authors wanting to use C++11's constexpr
> > feature is that the same implementation must be provided for both the case
> > of function invocation substitution and for execution at runtime. Due to the
> > constraints on constexpr function definitions, this can force an
> > implementation of a library function to be inefficient. To counteract this,
> > I'd like to propose the addition of a builtin:
> >
> > bool __builtin_constexpr_p()
> >
> > This builtin would only be supported within constexpr function
> > definitions. If the containing function is undergoing function invocation
> > substitution, it returns true. Otherwise, it returns false. Hence we can
> > implement library functions with a pattern like:
> >
> > constexpr int constexpr_strncmp(const char *p, const char *q, size_t
> > n) {
> > return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 :
> > constexpr_strncmp(p+1, q+1, n-1);
> > }
> > __attribute__((always_inline)) constexpr int my_strncmp(const char *p,
> > const char *q, size_t n) {
> > return __builtin_constexpr_p() ? constexpr_strncmp(p, q, n) :
> > strncmp(p, q, n);
> > }
> >
> > Does this seem reasonable?
>
>
> Yes, especially the primary functionality. However, I have some
> concerns about the interface. Let me hypothesize a different
> interface:
>
> This stays the same...
> > constexpr int constexpr_strncmp(const char *p, const char *q, size_t n)
> > {
> > return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1,
> > q+1, n-1);
> > }
>
>
> But here we do something different on the actual declaration:
> >
> > [[constexpr_alias(constexpr_strncmp)]]
> > int strncmp(const char *p, const char *q, size_t n);
>
>
> When parsing the *declaration* of this function, we lookup the
> function name passed to constexpr_alias. We must find a constexpr
> function with an identical signature. Then, at function invocation
> substitution of strncmp, we instead substitute the body of
> constexpr_strncmp.
>
> This seems more direct (no redirection in the code), and it also
> provides a specific advantage of allowing this to be easily added to
> an existing declaration in a declaration-only header file without
> impacting or changing the name of the runtime executed body or
> definition.
I really like this approach.
> -Chandler
>
> PS: Sorry for the dup Clang folks, the GCC list doesn't like my mail
> client.
(Likewise)
