Boost logo

Boost :

Subject: Re: [boost] [histogram] should some_axis::size() return unsigned or int?
From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2018-12-03 16:23:42

> On 3. Dec 2018, at 16:11, Brook Milligan <brook_at_[hidden]> wrote:
>> On Dec 3, 2018, at 8:26 PM, Hans Dembinski via Boost <boost_at_[hidden]> wrote:
>> So an elaborate solution is to make a new integer type `axis::size_type` for axis objects, which wraps an `int` and is implicitly convertible to `int`, but implements comparison operators with `int` and `unsigned` types to yield the naive results without warnings:
>> Method signature:
>> axis::size_type my_axis::size() const
>> Behaviour of axis::size_type:
>> axis::size_type s = 0;
>> assert((s-1) == -1); // ok, uses custom operator-(axis::size_type, int)
>> assert(-1 < s); // ok, uses custom bool operator<(int, axis::size_type)
>> assert(s < 1u); // no warning, uses custom operator<(axis::size_type, unsigned)
>> The only "problem" that I can see with this solution is that I have to implement a lot of operators and write a lot of additional tests, etc. But it is most direct solution to the problem that I can see.
> You are aware of the Boost operators library, right? That dramatically reduces the task of writing operators and would seem appropriate here. From reading the thread, this seems like the best solution as it allows you to support the full range of operations that you deem appropriate for balancing the requirements. X::size_type really should be an opaque type anyway, so as long as it interoperates with native types as expected you should be fine.

I am aware of the Boost operators library, but it is good that you remind me. If I allow my size_type to be implicitly convertible to int, I do not even have so many operators to implement. Implicit conversions are often bad, but it may be ok here.

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