Le 06/05/13 00:21, Rob Stewart a écrit :
On May 5, 2013, at 4:01 PM, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> 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