Preconditions

Before a client calls any function of Time(3C++), it is the client's responsibility to see to it that the preconditions for that function, if any, are satisfied. Failure to satisfy a precondition leads to undefined behavior. A core dump or an infinite loop might result; even worse, a problem might not turn up until much later in a way that would be difficult to trace.

An example of function with a precondition is the three-parameter Time constructor. One of the preconditions states that the arguments must represent a valid date. If this precondition is not satisfied--for example if the client does this:

       Time t(1989,Time::february,29);

then the behavior of the constructor is undefined (a core dump is one possible behavior).

There are generally two ways for a client programmer to guarantee that preconditions are satisfied:

• Correctness arguments based on the static program text can be used to prove that preconditions are satisfied. For example, we can argue that the following code:

         for(unsigned d=1;d<=31;d++){
             Time t(y,Time::january,d);
         }
  

  satisfies the precondition of the Time constructor because the month of January always has 31 days, regardless of the year.

• The client may explicitly check the precondition. The Time(3C++) component is designed to make such checking easy. For example, prior to using the Time constructor, the client can call the static member function Time::valid_date():

         Time t;
         if( Time::valid_date(y,m,d) ){
             t = Time(y,m,d);
         }
  

  Note that the cost of checking is borne by the client, not the constructor.