On Thu, Sep 05, 2013 at 11:02:36AM -0500, Dick Hollenbeck wrote: > Says you. Says me: having the the bits in the instance block matter. > > > I guess if what I have to say is going to be labelled as irrelevant right out > the box, I'd > be wasting my time continuing.
Strange that, said by someone which a little while ago told that data could even be on the moon and it's all a question of interface... I'd like you to notice that in my first message I was concerned about performance of an object vs a simple integer. These things should be a) readily copyable and b) readily passed around by value, from the common usage pattern I've seen. >From a performance standpoint I'd roughly evaluate the implementations (both in space and in time) in this order: int, std::bitset<>, std::vector<bool>, std::set<int>. The adhoc implementation should be roughly on par with bitset. However, what I meant was that there were 'bigger' proposals on the list to evaluate. Something like std::bitset (i.e. something inherently configured and limited at compile time) clearly is not adequate for these proposals. std::set<int> (usually a balanced tree) is the bigger and slower and IMHO only would have a meaning if we allowed arbitrarily large and sparse layer numbers. std::vector feels a good compromise. An std::bitset<> or a int64_t would be useful if we put a cap of maximum 64 or whatever number of simultaneous layers. With an 'adequate' layerset structure that could be arranged. Am I still wasting your time? -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
