This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] complex comparison operators


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]