Date/time class changes to handle extended date ranges

R.F. Pels ruurd at
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

	basic_string<char>::basic_string(const char*);
	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

More information about the kde-core-devel mailing list