Re: [boost] [chrono/date] validated versus valid dates

Subject: Re: [boost] [chrono/date] validated versus valid dates
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-05 18:21:16

On May 5, 2013, at 4:01 PM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:

> Allowing to build dates that are not validated doesn't mean that they are not valid. A validated date is always valid. E.g
> 
>  date d(year(2013), may, day(5));
> 
> d is not a validated date but is valid.
> 
> Having a is_validated() function in addition to is_valid() could have its uses
> 
>  assert(  ! d.is_validated() && d.is_valid()  );
> 
> is_validated() function forces to use a bit to store this information on the date representation, but it improves the performances of the is_valid() function.
> 
> Moving from a possible unvalidated to a validated one would need
> 
>  date d1;
>  ...
>  date d2(d1.year(), d1.month(), d1.day(), check);
> 
> Instead of this a validate factory makes this clearer
> 
>  date d1;
>  ...
>  date d2 = validate(d1);
> 
> 
> date validate(date const& dt)
> {
>  if (dt.is_validated()) return *this;
>  else if (dt.is_valid())
>  {
>    date res(dt);
>    res.set_validated_(); // this is private
>    return res;
>  }
>  throw bad_date();
> }

The basic idea is reasonable, but I suggest a couple of alternatives. First, I see no value in making is_validated() public. Second, validate() should return void:

void
date::validate()
{
   if (!is_valid())
   {
      throw bad_date();
   }
}

bool
date::is_valid()
{
   if (validated())
   {
      return true;
   }
   // do validation
   if (valid)
   {
      validated_ = true;
   }
   return valid;
}

Usage:

date d1;
d1.validate(); // throws bad_date
date d2(year(2013), may, day(5));
d2.validate();
assert(d2.is_valid());

___
Rob
(Sent from my portable computation engine)