Date/time class changes to handle extended date ranges
ruurd at tiscali.nl
Mon Feb 20 01:37:02 GMT 2006
On Monday 20 February 2006 00.42, Guillaume Laurent wrote:
>> And that is exactly the reason why this class should not be a QDate
>> specialistion, should not have conversion operators that produce a QDate
>> and should not have a name that could even remotely give the impression
>> that it has something to do with a QDate. This class CAN NOT BE a plugin
>> for QDate because its contract is wider than the contract of QDate.
> Uh, all string classes (std::string, QString, etc...) have conversions for
> plain old char*.
Tss! Not true. That it is true that basic_string<char> has
const char* c_str() const;
const char* data() const;
is because there is a one-on-one conversion possible from basic_string<char>
to char* and vice-versa. However, basic_string<wchar_t> does NOT have those
conversions. Besides. These are conversions that can be done without any
exceptions to the rule.
> Having KDate providing a toQDate() method makes perfect
> sense to me, even if it can yield an invalid object in some cases.
Bah. That's BAD. BAD BAD BAD. Look at the boilerplate error checking example I
R.F. Pels, 3e Rompert 118, 5233 AL 's-Hertogenbosch, The Netherlands
+31736414590 ruurd at tiscali.nl http://home.tiscali.nl/~ruurd
More information about the kde-core-devel