C++ Best Practices – Handling Unsigned Ints

Since you are working on a geometric API, I guess you are not only interested in intersection of lines and spheres, but have also more exciting projects.

A natural approach to solve your problem of representing values for intersection would be to define a type for geometric figures so that you can represent:

• Points
• Lines
• Spheres
• Intersections that you cannot compute (kind of symbolic intersection)
• Union of figures

Once you have done that, your intersection algorithm can gobble two figures and return a figure, computed by using

(A + B + ...).(C + D + ...) = A.C + A.D + B.C + B.D + ...

where I denote the union by + and the intersection by . and where A, B, C, D and the dots can be a point, a sphere, a line or an intersection you cannot compute.

To some extent, this approach gives satisfying results and may give the feeling that it is the right solution to the problem.

There are however a lot of problems with this approach, that you should be aware of:

1. Intersection that you cannot compute tend to absorb everything, i.e. intersecting anything with an intersection that you cannot can yield an intersection that you cannot compute.

2. If you intersect two spheres, it yields a circle, that you cannot compute, not because you cannot find which circle it is, but because you cannot represent circles. If you choose to add circles to your vocabulary, you have to figure out how to compute intersections with all other figures you may have. So if you have n base figures you should deal with n^2 type of intersections. So, choosing a rich vocabulary of figures without relying on ``intersections you cannot compute'' is not an option.

3. Even if you restrict yourself to the rassuring realm of algebraic figures (defined by polynomial equations), computing intersections is far from trivial. What you are trying to do is to compute a minimal set of generators of the reduced ideal defined by your intersection, so do not expect to be able to do this on more than a few examples. You should regard anything you are able to compute as a lucky accident.

There are major differences between throwing exceptions and returning error objects, in particular,

• exceptions create many new code-flow paths which are not explicitly visible in the source code,
• callers have no idea what kinds of errors they can expect,
• they propagate automatically, and
• they make the code much less verbose and easier to read and write.

Rust tries to get the best of both worlds by banning exceptions (this eliminates the first two points) and by having the try! macro (this deals with automatic propagation and verbosity).

Your solution deals with the first two points only and there is no straightforward way to have the latter two. Your * operator is not an equivalent of try!. The equivalent of

x = try!(foo());

is simply not possible to do in C++ (without language extensions).

That said, feel free to use your class, though as @Deduplicator points out, your Result class can only hold exception objects of dynamic type std::exception, which is probably not what you intended. The easiest way to accomplish what you want is to use std::exception_ptr to hold the exception object.

Or, better yet, just use exceptions -- that's what the language was designed for after all.