[libstdc++,C++11] Library style for user-defined literal operators
Let me try that again. Sorry for the dupe and the bad subject in the previous message. This patch fixes a small stylistic nit in the user-defined literal operators in the standard library.I propose we prefer: operator""suf - with no spacerather than: operator"" suf - with spaceIt is only strictly necessary to have no space between quotes and suffix identifier when the suffix identifier is a keyword. On the other hand, consistently using no space means never having to say you're sorry. It is also consistent with our style of not having space between operator and, say '+'. I believe that first allowing the space in the first place might have been a mistake in the standard. The (to be committed tonight) literal operators for complex need to have no space because the suffix is 'if'. We might as well be consistent. I think this is better style too.Ed CL_lit_oper_style Description: Binary data patch_lit_oper_style Description: Binary data
Re: Re: [C++11] PR54413 Option for turning off compiler extensions for numeric literals.
On 11/06/12, Jason Merrill wrote:
> Why three separate flags?
I thought extra flexibility might be wanted. On the other hand, *I* would
never turn off just one set. I expect a food fight over all flags. Also, if,
as seems reasonable, strict ANSI turns off all gnu suffixes then having one
flag for all seems sufficient and would cover most cases.
Also, if a user tries to create a fixed-point literal in C++ you get an error
about not supported fixed-point anyway. So maybe this should always be
referred to user-defined literals without a flag?
Finally, these machine-defined literals seem obscure to me.
So how about
-f[no-]ext-numeric-literals
or maybe
-f[no-]gnu-numeric-literals
for everything?
>
> The flag(s) need(s) to be documented in doc/invoke.texi.
OK.
>
> > @@ -721,7 +733,12 @@
> > case OPT_std_c__1y:
> > case OPT_std_gnu__1y:
> > if (!preprocessing_asm_p)
> > - set_std_cxx1y (code == OPT_std_c__11 /* ISO */);
> > + {
> > + set_std_cxx1y (code == OPT_std_c__11 /* ISO */);
> > + cpp_opts->imaginary_literals = 0;
> > + cpp_opts->fixed_point_literals = 0;
> > + cpp_opts->machine_defined_literals = 0;
> > + }
>
> I think I would disable the built-in extension in both C++11 and C++1y
> if we're in ISO mode, and leave it enabled if we're in GNU mode.
>
I'll do this.
> I think the ideal behavior for these suffixes would be to treat them as
> user-defined literals if a corresponding literal operator is available,
> or use the built-in extension if not. But that doesn't need to happen now.
I thought about that. We'd need some machinery that would allow cpp to query
what has been declared already. Maybe it's already there?
>
> Jason
Thanks for looking at this.
Ed
Re: [patch] Apply recent DRs resolutions to libstdc++
I looks like there were a couple #ifdef __GXX_EXPERIMENTAL_CXX0X__ in the patch. I think you want to change these to #if __cplusplus >= 201103L ? Regards, Ed
Re: Re: [wwwdocs] C++14 support for binary literals says Noinstead of Yes
On 04/30/13, Jakub Jelinek wrote: On Tue, Apr 30, 2013 at 11:23:49AM -0400, Jason Merrill wrote: > I've updated the webpage. Perhaps it would be nice if we had some testsuite coverage for it too, right now unless I'm blind there are exactly 2 testcases, using one 0b... number in each in g++.dg/. At least port gcc.dg/binary-constants-*.c to C++ (or move to c-c++-common/) and perhaps have something where the numbers are used in some C++ only contexts (templates, constexprs, whatever). Jakub I've been meaning to throw together a user-defined literal test for octal and hex. I'll add binary literals too. I've used literals on octal and hex numbers and I know they work but it would be nice to have in the testsuite. Usage of literal operators on octal, hex, and now binary literals are explicitly called out in the standard (somewhere). Ed
Re: Re: Implement N3642 - User-defined Literals for Standard Library Types
On 05/31/13, Ed Smith-Rowland<3dw...@verizon.net> wrote: > ... > 1. Put the precision first in upper case. As a matter of style I > prefer 123456L to 123456l for normal literals anyway. Also, the > precision snuggles next to the number - then you modify it. That seems > logical to me. Also, if we involve in this someday, those > literals *have* to be all caps (for the old literals). It seems using > lower case precision indicators for decimal would be inconsistent. I must withdraw the comment about decimal literals needing to be all caps. That's wrong. The letters need to be all uppercase *or* all lowercase. You can't have mixed case. I'll shut up now and post this somewhere else. Ed
RE: [Bug libstdc++/56430] In __airy: return-statement with a value, in function returning 'void'.
Here is an overdue patch for the Airy function. I repair the void function and I out two Airy functions as C++ extensions. Built and tested on x86_64-linux. OK? Ed CL_Airy Description: Binary data patch_Airy4 Description: Binary data
Re: more distributions
On 03/01/13, Ulrich Drepper wrote: I have a few more distributions to be added. The triangle distribution is the result of combining to uniform distributions and therefore quite frequently used. The von Mises distribution (the simple, 2D version) would be the first circular distribution. The patch depends on the __math_constants patch. Excellent! I was looking at a paper: Modeling Data using Directional Distributions by Inderjit S. Dhillon and Suvrit Sra that looks like it would be very similar to your multi-variate normal distribution. These generalize von Mises to higher dimension. Is this your next target? Thanks for the math constants too. Ed
Re: Re: [PATCH] C++ math constants
On 02/21/13, Alec Teal wrote: On 21/02/13 16:32, Ulrich Drepper wrote: > How about the attached file as a start for . I used the > constexpr approach (instead of function calls) and replicated the > constants that are available in in Unix. > > What other constants to add? Pi/3 ln(3) ln(10) (for base conversions) sqrt(3) sqrt(5) sqrt(7) 1/e I'll write down what I use in my day to day stuff, keep you posted. I use the Euler constant a *lot* in special functions. Also, I use the golden ratio to size dialog boxes in GUI work. // Constant @f$ @f$. static constexpr _RealType __pi_third(1.0471975511965977461542144610931676L); // Constant @f$ \gamma_E @f$. static constexpr _RealType __gamma_e(0.5772156649015328606065120900824024L); // Constant @f$ \phi = (1 + \sqrt(5))/2 @f$. static constexpr _RealType __golden_ratio(1.6180339887498948482045868343656381L);
Re: [C++-11] User defined literals
Jason, I split the changelog into four parts and tweaked some of the content and formatting. Ed CL_udlit_gcc_c-family Description: Binary data CL_udlit_gcc_cp Description: Binary data CL_udlit_gcc_testsuite Description: Binary data CL_udlit_libcpp Description: Binary data
Re: Re: [C++-11] User defined literals
Oct 26, 2011 03:39:09 PM, ja...@redhat.com wrote: On 10/26/2011 02:00 AM, Ed Smith-Rowland wrote: > The patch was bootstrapped and regtested on x86_64-linux-gnu. Really? I ran into a warning about the unused "suffix" parameter to interpret_integer. So I've fixed that error. I also added a couple of comments, and implemented the change to check_literal_operator_args that I wondered about a while back. And checked it all in. But we aren't quite done, I think: I notice that the lookup of operators doesn't match what's in 2.14.8. For instance, I don't think this should be accepted: double operator"" _foo (long long unsigned); double d = 1.2_foo; The lookup described in 2.14.8 involves looking through the overload set for a particular signature before doing normal overload resolution. Also, we don't need to worry about argument-dependent lookup for these operators, since none of the arguments can have associated namespaces. So I think we can use lookup_name rather than lookup_function_nonclass, only look it up once in cp_userdef_numeric_literal, and then only build one call depending on the contents of the overload set. Jason Jason, Thank you Jason and Tom for your help in getting this together an putting up with my slowness. That warning about unused suffix didn't blow up the build. I'm surprised Werror didn't kill it. I'll check out these other issues as soon as I clean out all my work and rebuild on a clean tree. I guess I need to look at what kind of number I get when processing a numeric literal. Thanks again.
Re: Re: [C++-11] User defined literals
>
> Oct 31, 2011 11:56:59 AM, ja...@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
[C++11] Add cstdalign to precompiled headers.
Subject says it all. It's a one liner. Bootstrapped on x86_64-redhat-linux. Testing is ongoing. Ed patch Description: Binary data CL Description: Binary data
