kicad-developers team mailing list archive

[Vladimir Uryvaev <vovanius@xxxxx>]

В сообщении от Четверг 23 июня 2011 10:49:44 автор Lorenzo Marcantonio 
написал:
> On Wed, 22 Jun 2011, Wayne Stambaugh wrote:
> > Under and overflow checking is one place where object oriented design has
> > the potential to be more robust than macros.  It also can help prevent
> > the math issues when mixing types.
> 
> Isn't almost every computation done in FP in kicad regarding drawing
> code? Also IIRC the geometry classes are FP based too... so the only
> place int-based would be the storage... heck, we could even say
> 'everything is in metres' :P

FP is rounding. Does not matter why you'll see some day your track width 
0.00020000000001 m or 0.00019999999999976 m it will not pass DRC on 
manufacturer side. That's why fixed point is still there.

> >> decimils, millimeters in all whose variables? I did this, and say, it's
> >> not so simple as you imagine. My approach is seem to be most clear and
> >> bug-avoiding one i can work out. Do you know better one? But why did
> >> not you already proposed it? ;)
> 
> My proposal is: handle/save *everything* in nano/metres whatever like
> the decimils today. Unit conversion is relegated only to UI, which, in
> fact, is handled by 3-4 function in all (I studied that when I've done
> the 'universal unit' patch which allow to type 3,2mm in an edit box even
> when units are set to imperial; apart from the converter itself there were
> less than 50 lines of changes IIRC, done the work in about a day). So you
> *could* build your class infrastructure but at the end the
> conversion functions would be called only 4 times in all the kicad
> sources (and most probably these call would be in the same source file).
> OOP is bad when functional is sufficient (yes, not even imperative, it's
> a functional solution, too:D)

If you like functional/imperative paradigm it's you own opinion. I even prefer 
to use paradigm that give me better soultion.

> 
> OK, my proposal instead is a simple double type (you can typedef it as
> 'metric_size' if you want) and 2/4 functions which are already in
> place... also you can already pass it to geometric routines like kbool
> or boost::polygon (don't remember the name) as is (your LENGTH class
> would need getter and/or cast operators I suppose to interoperate
> correctly).
> 
> My bottom line is: why keeping the unit along the datatype when
> everything *except* the user don't mind about the unit itself?

Because one day man invented type checking, and i gonna exploit it to do unit 
conversion.

There would be no problem switch back to any 'plain' type, just typing

typedef int LENGTH;

But currently i would prefer if all unit checking is done by compiler, not 
human.



-- 

--- KeyFP: DC07 D4C3 BB33 E596 CF5E  CEF9 D4E3 B618 65BA 2B61