What's the right way to implement integer division-rounding-up?

Question

It's very common to need to divide integers but get the result rounded up rather than down. For a while now, I've been using the following function for that mini-idiom:

template <typename S, typename T>
constexpr inline S div_rounding_up(const S& dividend, const T& divisor) 
{
    return (dividend + divisor - 1) / divisor;
}

This has (at least) the following deficiences, or what may be seen as deficiencies:

• While it works "as promised" with negative operands - it's called div_rounding_up - it would probably make more sense to have this kind of function round away-from-zero, since x / y for negative x and positive y rounds towards zero. In other words, maybe what I should be implementing is div_rounding_away_from_zero, which would be commutative with inversion: Letting auto f = [&y](const S& x) { return div_rounding_away_from_zero(x,y); } we would have f(-x) == -f(x).
• Overflow near the end of the domain of S.
• Possibly weird behavior when sizeof(S) > sizeof(T).
• long function name...

While you can easily think of ways of addressing each of these, they then result in other possible deficiencies, like conditionals in the code, or a reliance on calculating the modulus which may be expensive.

So is there a "right way" to implement this? By "right" I mean semantically pleasing, efficient, avoiding as many of the deficiencies above, and hopefully widely-used.

Notes:

• If you think the function should be strictly constained to only work with non-negative arguments, say so. That would be a bit problematic IMHO since we don't want to constrain the types to be unsigned, and we don't want to check the operands' signs. That seems like something I would use a contact for - and C++ doesn't have them yet.
• Is using std::div and variants a good idea here?
• Performance is more important than readability. At worst one can add a comment.
• Code should not be single-architecture-specific (but if you want to ifdef-else for different architectures then be my guest).
• Code should not assume a specific compiler.

Answer 1

Possibly weird behavior when sizeof(S) > sizeof(T).

It would probably be better to use a single type argument, and let the user deal with the conversion that they want. This is the approach used by the standard library math functions.

Overflow near the end of the domain of S.

A remainder based rounding does not have this problem.

reliance on calculating the modulus which may be expensive.

You are already calculating a division, which is expensive. On x86 at least, the division instruction stores the remainder in a register, and a decent implementation of std::div will use it. A modern compiler will even be able to optimize explicit use of division and remainder operation as well.

Is using std::div and variants a good idea here?

Sure.

If you think the function should be strictly constained to only work with non-negative arguments, say so.

I think you should at least require that arguments must have the same sign. The direction of rounding of both division and remainder operator (also by extension std::div since C++11) is implementation defined. With this requirement, there is no difference between rounding away from zero, and rounding up, since no supported result is negative.

template <typename T> // single type argument
constexpr T           // constexpr implies inline
div_round_up
(const T& dividend, const T& divisor) 
{
    // no overflows, only 1 expensive operation
    std::div_t dv = std::div(dividend, divisor);
    return dv.quot + (!!dv.rem);
}