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

List:       koffice-devel
Subject:    Re: KSpread 2.0: some issues
From:       Stefan Nikolaus <stefan.nikolaus () kdemail ! net>
Date:       2006-12-24 12:46:43
Message-ID: 200612241346.47997.stefan.nikolaus () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday, December 24, 2006 01:14:19 PM Tomas Mecir wrote:
> What is the advantage over my version though ? With the exception of
> complex numbers, it's exactly the same thing, and if we would to add
> them, we'd have to add them separately instead of just using Number
> for that. Hence I believe my version would work better :)

The mentioned type distinctions are not necessary. Otherwise each operator 
will look something like:

Float Float::operator*( Float o )
{
	if ( type() == TYPE_FLOAT && o.type() == TYPE_FLOAT )
		return f * o.f;
	else if ( type() == TYPE_COMPLEX && o.type() == TYPE_FLOAT )
		return c * o.f;
	else ...
}

Or how are you planning to avoid this?

Another advantage is, that we can typedef Float to double, which is not 
possible, if it is also used for complex numbers. ;)

The original idea of Float was, that, if we do not use any special arbitrary 
precision type for floating point numbers, but simply double, it falls back 
to the builtin operations for double without ANY kind of extra stuff, like 
type conversions or type distinctions.

Regards,
Stefan

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


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