kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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