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

6 May 2013


      Le 06/05/13 00:21, Rob Stewart a écrit :
...
On May 5, 2013, at 4:01 PM, "Vicente J. Botet Escriba"  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());
I thought about this alternative. As is_valid must be const, this 
request validated_ to be mutable. I wanted to use one of the unused bits 
to store this information and I don't know if I can declare a bitfield 
mutable. Can I?

Best,
Vicente