This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] complex comparison operators
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Sat, 6 Nov 2010 04:51:21 -0500
- Subject: Re: [v3] complex comparison operators
- References: <20101105210723.174a719b@shotwell>
On Fri, Nov 5, 2010 at 11:07 PM, Benjamin Kosnik <bkoz@redhat.com> wrote:
>
> This patch is not applied.
>
> As part of the duration constexpr-ifcation, the utility of constexpr
> comparison operators became noticeable.
>
> Original use case:
>
> static_assert(_Period::num > 0, "period must be positive");
>
> or
>
> static_assert(system_clock::duration::min() <
> system_clock::duration::zero(), "a clock's minimum duration cannot be
> less than its epoch");
>
> So, I went looking for other areas in the library that might benefit
> from constexpr comparison operators.
>
> Audit rubric:
> 1) if static constexpr function can return it
> 2) if some other class can contain it as a static constexpr data
> 3) has one of operator ==, !=, >, >=, <, <=
> 4) implementation of comparison operators calls only constexpr functions
>
> This turns up std::complex operators == and != as candidates.
good catch. They should be marked constexpr. Since we now have the
close that `constexpr' is silently ignored if the function template
specialization
fails to be constexpr, that would be hamless.
>
> Close:
> 1. tuple, pair, and <random>'s engines have operator ==, but no
> constexpr construction.
That would have required that every template argument of pair<> be a literal
type (at least that was the requirement some time ago, I do not know whether
that changed.)
> 2. array, but the the operator implementations are not constexpr.
>
> I think this should go in, but am waiting for a second.
>
> The required complex specializations are
> literal types and comparing them at compile time seems worth the
> (minimal) effort. A potential problem (?) is that the primary std::complex
> template does not mark real(), imag() or any of the constructors as
> constexpr. (I believe this is incorrect: it means that compile-time
> behavior is different for specializations and primary templates, which
> seems misleading.)
Makeing the primary template a literal type would have imposed a hardship
on which type can be used to it -- e.g. the template argument would have
to be a literal type.
>
> Since the primary template for complex is not guaranteed to be useful
> for other than the required classes, I'm not quite sure this is a
> reason that is credible.
We provide an implementation for the primary template so that people
can use it for things like complex<bigfloat>, even if the standard does not
require it. From the standard point of view, we could require only
`literalness'
classes that are required to exist.
-- Gaby