On 10/27/2017 12:29 AM, Martin Sebor wrote:
IMO, a good rule of thumb to follow in class design is to have
every class with any user-defined ctor either define a default
ctor that puts the object into a determinate state, or make
the default ctor inaccessible (or deleted in new C++ versions).
If there is a use case for leaving newly constructed objects
of a class in an uninitialized state that's an exception to
the rule that can be accommodated by providing a special API
(or in C++ 11, a defaulted ctor).
Yet another rule of thumb is to make classes that model
built-in types behave as close to the built-in types as
possible, making it easier to migrate between the custom
types and the built-in types (and vice versa), to follow
expectations, and to avoid pessimization around e.g., otherwise
useless forcing initialization of such types in containers/arrays
when you're going to immediately fill in the container/array with
real values.
BTW, there's a proposal for adding a wide_int class to C++20:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0539r1.html
and I noticed:
~~~
26.??.2.?? wide_integer constructors [numeric.wide_integer.cons]
constexpr wide_integer() noexcept = default;
Effects: A Constructs an object with undefined value.
~~~