[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Date/time class changes to handle extended date ranges
From:       "R.F. Pels" <ruurd () tiscali ! nl>
Date:       2006-02-20 1:37:02
Message-ID: 200602200237.03501.ruurd () tiscali ! nl
[Download RAW message or body]

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 
gave.

-- 
R.F. Pels,  3e Rompert 118,  5233 AL  's-Hertogenbosch,  The Netherlands
+31736414590        ruurd@tiscali.nl       http://home.tiscali.nl/~ruurd

[prev in list] [next in list] [prev in thread] [next in thread]