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