В сообщении от Четверг 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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
