On 24/01/14 16:20, waldo kitty wrote: > On 1/23/2014 5:01 AM, Lukasz Sokol wrote: > >> Maybe Something like: (but this is with type TOptionMinMax = >> [mmNone, mmMin,mmMinMax, mmMax]) > > i wanted to thank you, lukasz, for your input... it has made me take > another look while rewriting to implement your ideas... > > during this process i had an epiphany... that being that i don't need > three individual states for each option since one of those states is > ANDing two of those states... since i'm ANDing all valid > possibilities anyway, this will free up 5 'bits' or 'scores' leaving > room for more options if needed in the future... it will also lessen > the complexity of the CASE "decision tree" but not by very much... > > with the above epiphany and some other information i have acquired, > i'm now in the process of rewriting the app... i suspect it will take > me a day or two to get to the point i was at previously with the > operational and in-use code but i still wanted to say thanks to you > and others who provided ideas, insights and information ;) :) >
Glad to hear that not all I thought of is a brain fart ;) However I'm still curious : why use bits directly, when you can have a set/'enum' of possible choice(s), guaranteed to be distinct - so you can't physically set OptionA twice, by definition, and then make the Options be an array of the options? Yes it may be using Sizeof(set) x num options (1 byte per option?) but then it's not for you to worry any more about the bits - the compiler will care for that and you can go rethink the logic ;) and also readability and maintainability +100 ;) But IMHO of course and YMMV ;) Kind Regards, -L. ;) _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal