Constraint checking in constructor initialization lists

Question

This situation is related to How to make a constraint on the parameters of the constructor, but it's slightly different.

You want to initialize a non-default-constructible member but need to check for constraints before constructing it.

Example:

(Please note that this is really just an example. Whether one should use unsigned integers instead in this specific situation is discussable, but the question really is about the general case where you want to check in constructors)

You have the following class:

class Buffer {
public:
    Buffer() = delete;
    Buffer(int size) noexcept;
};
....


class RenderTarget {
public:
    ....
private:
    int width_, height_;
    Buffer surface_;
};

The constructor has to check the integer arguments for validness:

RenderTarget::RenderTarget(int width, int height) :
    width_(width), height_(height),
    surface_(width_*height)
{
    if (width_<0 || height_<0)
        throw std::logic_error("Crizzle id boom shackalack");
}

Note how Buffer does not have a default constructor, and the real constructor is noexcept, i.e. there is no way to catch an error.

When the integer arguments are negative, one has a hosed surface_ already. It would be nicer to do the constraint checking before using the constrained value. Is it possible?

Answer 1

Named Constructor

You can use a so called Named Constructor (see also https://isocpp.org/wiki/faq/ctors#named-ctor-idiom), and make the constructor private:

class RenderTarget {
private:
    RenderTarget (int w, int h) :
        width_(w), height_(h), buffer_(w*h) 
    {
        // NOTE: Error checking completely removed.
    }

public:
    static RenderTarget create(int width, int height) {
        // Constraint Checking
        if (width<0 || height<0)
            throw std::logic_error("Crizzle id boom shackalack");

        return RenderTarget(width, height);
    }

Named Constructors are interesting in case you have multiple constructors that may be ambiguous to use, e.g. Temperature <-- Celsius | Fahrenheit | Kelvin or Distance <-- Meter | Yard | Cubit | Kilometers | ....

Otherwise, (personal opinion) they impose an unexpected abstraction and also distraction and should be avoided.

Ternary Operator and throw

C++ allows in [expr.cond] the use of throw-expressions in one or both operands to the ternary operator (?:-operator):

RenderTarget(int w, int h) :
    width_(w<0 ? throw std::logic_error("Crizzle id boom shackalack") : w),
    height_(h<0 ? throw std::logic_error("Crizzle id boom shackalack") : h),
    surface_(w*h)
{}

If you do not store the arguments, you can also use ?: inside an expression, of course:

RenderTarget(int w, int h) :
    surface_(
       (w<0 ? throw std::logic_error("Crizzle id boom shackalack") : w)
     * (h<0 ? throw std::logic_error("Crizzle id boom shackalack") : h)
    )
{}

Or you combine the precondition-checking into a single operand:

RenderTarget(int w, int h) :
    surface_(
       (w<0||h<0) ? throw std::logic_error("Crizzle id boom shackalack") :
       w * h
    )
{}

Using the ?:-operator with a throw-expression inline can be very nice for basic constraint checking and avoids having to fall back to using a default constructor (if any), and then doing "real initialization" within the constructor body.

This can become a bit unwieldy for more complex scenarios.

Static Private Member

The best of both worlds can be used, of course:

private:
    static bool check_preconditions(int width, int height) {
        if (width<0 || height<0)
            return false;
        return true;
    }
public:
    RenderTarget(int w, int h) :
        surface_(
           check_preconditions(w,h) ?
           w*h :
           throw std::logic_error("Crizzle id boom shackalack")
        )
    {}

... or you write static functions for any member you need to precondition-check:

private:
    static Buffer create_surface(int width, int height) {
        if (width<0 || height<0)
            throw std::logic_error("Crizzle id boom shackalack")
        return Buffer(width*height);
    }

public:
    RenderTarget(int w, int h) :
      surface_(create_surface(w, h))
    {}

This is nice because you have the complete C++-machinery at hand for constraint checking, and for example can easily add logging. It scales well, but is a bit less handy for simple scenarios.

Answer 2

There is also the possibility of simplifying the problem by making size, height and width unsigned, which will prevent ever getting into a negative state.

class Buffer {
public:
    Buffer() = delete;
    Buffer(unsigned int size) noexcept;
};
....


class RenderTarget {
public:
    ....
private:
    unsigned int width_, height_;
    Buffer surface_;
};

The constructor has to check the integer arguments for validness:

RenderTarget::RenderTarget(unsigned int width, unsigned int height) :
    width_(width), height_(height),
    surface_(width_*height)
{
    // never a need to throw on negative values...
}

ADDITIONAL ERROR HANDLING APPROACHES:

If using the type to limit invalid values is not enough, there are many tried and tested ways to handle error situations beyond throwing exceptions, such as:

Buffer(int size, bool& success) {}

or

class Buffer {
...
    bool isValid()
};

or

template<typename T>
struct ValidatedValue
{
    ValidatedValue(T value, T min, T max)
        : _value(value)
        , _isValid(value >= min && value <= max)
    {
    }

    bool isValid() const { return _isValid; }
private:
    T _value;
    bool _isValid;
};

or ...

Many other alternatives.

There are pros and cons to every approach for validating data, but I generally recommend keeping the solution simple enough to be maintainable and readable, as often these solutions can be over engineered.

Answer 3

phresnel’s solution with inline throw and the suggestion in Curg’s answer to use unsigned integers both hint at a general solution here: using types to ensure that values are correct by construction.

If a width and height cannot be negative, making them unsigned could be a good choice—but if there is a maximum bound, you might need a more precise type to specify the invariants, such as:

template<class T, T min, T max>
struct ranged {
  ranged(const T v)
    : value_(v < min || v > max ? throw range_error("...") : v) {}
  const T value_;
};

Then you might say:

ranged<unsigned int, 0, 1600> width_;
ranged<unsigned int, 0, 1200> height_;

But then you might want to enforce that the width and height have an aspect ratio no greater than 16:9. So you can bundle them up into a Size type, and so on. That way, all the validation logic on the members of RenderTarget has been done by the time the constructor body begins.

This kind of encapsulation is fundamental to object-oriented programming: the public interface of an object cannot be used to place it in an invalid state, and the constructor is part of the public interface.