Boost logo

Boost :

Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Krzysztof Czainski (1czajnik_at_[hidden])
Date: 2014-08-05 12:36:47

2014-08-05 17:42 GMT+02:00 Robert Ramey <ramey_at_[hidden]>:

> Please don't forget, that not all requirements can be checked at compile
> time. For example: TotallyOrdered. Just by checking, that an expression
> (a<b) is valid and yields something boolable, you can't distinguish between
> TotallyOrdered, PartiallyOrdered, or maybe neuter.
> &lt;/quote>
> This is not true.
> requirements are on types - not on instantiations of types. If it can't be
> checked at compile time - it's not a type requirement - it's something else
> (perhaps a pre-condition).
> TotallyOrdered doesn't refer to some container that may or may not be
> sorted.
> It refers to the existent of a comparison function for the type which
> fulfills
> a number of requirements. To see this look at
> Here we can specify type requirements on functions which provide
> for a strict weak ordering. These can all be verified at compile time
> based on the properties of the types. Note that not all can be
> verified by the compiler as some depend upon the semantic definition
> of the function. But one doesn't have to know that runtime data to
> verify that the function meets the conditions for a strict weak ordering.
> To summarize - all type requirements can be verified when the code
> is written - but not all type requirements can be verified automatically
> by the compiler.
> So verification of by the compiler isn't perfectly exhaustive - but it's
> a heck of a lot better than what we usually do - which is nothing.
> Robert Ramey

What about this example:

struct Circ
  unsigned x;
  explicit Circ(unsigned i=0) : x(i%256) {}
bool operator<(Circ a, Circ b) { return (b.x-a.x)%256 < (a.x-b.x)%256; }

Is std::set<Circ> valid?

I think generally not, but... suppose that we know, that we're only going
to use values 0-127. In this case std::set<Circ> is valid.


Boost list run by bdawes at, gregod at, cpdaniel at, john at