lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [lmi-commits] odd/gpt e293170 1/5: Add an equality operator


From: Vadim Zeitlin
Subject: Re: [lmi] [lmi-commits] odd/gpt e293170 1/5: Add an equality operator
Date: Tue, 27 Apr 2021 20:19:06 +0200

On Tue, 27 Apr 2021 12:13:45 -0400 (EDT) Greg Chicares 
<gchicares@sbcglobal.net> wrote:

GC> branch: odd/gpt
GC> commit e2931707d25f64eba0db41696c78a60c19cf8d10
GC> Author: Gregory W. Chicares <gchicares@sbcglobal.net>
GC> Commit: Gregory W. Chicares <gchicares@sbcglobal.net>
GC> 
GC>     Add an equality operator
GC>     
GC>     It is anticipated that all but one line of this change will be expunged
GC>     soon enough.
GC>     
GC>     Unfortunately the shorthand
GC>       default: ==, !=, <, >, <=, >=;
GC>     proposed in
GC>       http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2014/n4126.htm
GC>     has not been embraced by C++20.
GC>     
GC>     SD-6 says: "in most cases it is expected that the presence of a feature
GC>     can be determined by the presence of any non-zero macro value".

 Interesting, I was sure that just being defined was enough. And
https://en.cppreference.com/w/User:D41D8CD98F/feature_testing_macros seems
to confirm it, even though it's non-normative.

GC> ---
GC>  gpt_commutation_functions.hpp | 29 +++++++++++++++++++++++++++++
GC>  1 file changed, 29 insertions(+)
GC> 
GC> diff --git a/gpt_commutation_functions.hpp b/gpt_commutation_functions.hpp
GC> index 54dc460..7d824fa 100644
GC> --- a/gpt_commutation_functions.hpp
GC> +++ b/gpt_commutation_functions.hpp
GC> @@ -113,6 +113,35 @@ struct gpt_scalar_parms
GC>      double               qab_spouse_amt  {                 0.0};
GC>      double               qab_child_amt   {                 0.0};
GC>      double               qab_waiver_amt  {                 0.0};
GC> +
GC> +#if defined __cpp_impl_three_way_comparison && 
__cpp_impl_three_way_comparison

 I.e. I believe that the part after "&&" is not really necessary here and
if we did want to be pedantic, I'd check for

        #if defined __cpp_impl_three_way_comparison && 
__cpp_impl_three_way_comparison >= 201907

But, again, IMO a simple check for defined-ness should really be enough
(and this is what I used for checking for "__cpp_char8_t").

 Regards,
VZ

Attachment: pgp0lJ6jCkZqc.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]