Boost logo

Boost :

Subject: Re: [boost] a safe integer library
From: Brook Milligan (brook_at_[hidden])
Date: 2016-01-12 16:32:33

On Jan 12, 2016, at 1:50 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> It's going to be a little trickier than that. One basic problem is that there more than two cases, yes, no, have to check at runtime.

Yes, but I expected this to boil down to one of two cases depending on policy:

- yes, no, or fail to compile, or
- yes, no (will compile but may or may not invoke a runtime check)

I thought those were basically the options for any of the operations and that the difference was based upon the policy choice. Do I misunderstand?

> The above return a "checked_result<interval_t>" - which is decribed in another part of the documentation. Basically its similar to "optional" so it either returns a valid new interval or an error condition which you can test for.

It seems that the best correspondence might be something like the following:

        typedef safe_int<int8_t> narrow_type;
        int x = { /* potentially something large */ };
        if (checked::cast<narrow_type>(x).no_exception()) {
        } else {

Is that the correct semantics? Should I be worried about the following comment from your docs: "Note that this type is an internal feature of the library and shouldn't be exposed to library users because it has some unsafe behavior.”? That seems worrisome and was a reason this did not register earlier.

This solution suggests that wrapping this particular construct in something that is unambiguously safe would be a good idea:

        template < typename R, typename T >
        bool is_convertible<R>(T const& t)
        { return checked_cast<R>(t).no_exception(); }

Does that make sense?


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