From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24422 invoked by alias); 31 Oct 2011 16:44:37 -0000 Received: (qmail 24408 invoked by uid 22791); 31 Oct 2011 16:44:32 -0000 X-SWARE-Spam-Status: No, hits=3.4 required=5.0 tests=AWL,BAYES_40,BOTNET,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from vms173007pub.verizon.net (HELO vms173007pub.verizon.net) (206.46.173.7) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 31 Oct 2011 16:44:16 +0000 Received: from vznit170070 ([unknown] [172.18.12.134]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LTX00C4JVTFDV23@vms173007.mailsrvcs.net> for gcc-patches@gcc.gnu.org; Mon, 31 Oct 2011 11:44:04 -0500 (CDT) Received: from 205.167.170.13 ([205.167.170.13]) by vznit170070 (Verizon Webmail) with HTTP; Mon, 31 Oct 2011 11:44:03 -0500 (CDT) Date: Mon, 31 Oct 2011 17:58:00 -0000 From: 3dw4rd@verizon.net To: jason@redhat.com Cc: gcc-patches@gcc.gnu.org Message-id: <1988108989.8568759.1320079443745.JavaMail.root@vznit170070> Subject: Re: Re: [C++-11] User defined literals MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg02861.txt.bz2 > > Oct 31, 2011 11:56:59 AM, jason@redhat.com wrote: > > On 10/30/2011 01:13 PM, Ed Smith-Rowland wrote: > > + /* Look for a literal operator taking the exact type of numeric argument > > + as the literal value. */ > > Is this right? Do numeric literals only get here with type unsigned > long long or long double? Yes, the preprocessor interprets a numeric literal either as integral or floating point in the usual way. If an unrecognized suffix is found then the numeric part is interpreted as unsigned long long or as long double as appropriate. This happens in the lexer. Anything with a double quoted front part is sent to string literal. Anything with a single quoted bit is set to char literal. > > + while (fns) > > { > > tree tmpl_args = make_char_string_pack (num_string); > > - decl = lookup_template_function (decl, tmpl_args); > > - result = finish_call_expr (decl, &args, false, true, tf_none); > > - if (result != error_mark_node) > > + tree fn = OVL_CURRENT (fns); > > + tree argtypes = NULL_TREE; > > + if (TREE_CODE (TREE_TYPE (fn)) != LANG_TYPE) > > + argtypes = TYPE_ARG_TYPES (TREE_TYPE (fn)); > > + if (argtypes != NULL_TREE > > + && same_type_p (TREE_VALUE (argtypes), void_type_node)) > Let's wait to make the pack until we find a template. Also, you should > be able to just check for TEMPLATE_DECL since we won't accept a literal > operator template with different parameter types. > For string and character literals, we can still just build up a call; we > only need to walk the overload list here for numeric literals. I found that if you don't walk the overload list for chars, a char could be routed to the operator taking wchar_t for example. This is similar to the comment you made for numeric literals - 1.2_foo potentially going to operator"" _foo(long long unsigned). I think for strings you may be right. Jason