Re: binary search trees & binning
Re: binary search trees & binning
- Subject: Re: binary search trees & binning
- From: Mike Abdullah <email@hidden>
- Date: Wed, 16 Apr 2008 23:27:24 +0100
On 16 Apr 2008, at 22:34, John Stiles wrote:
Honestly, I can't see value in always coding to CFArray just so I
can rip out the back end later if I don't like the results.
If anything, it would make more sense to me to use NSArray for that
purpose, since I know working with and subclassing NSArray will be
easy and painless. Core Foundation is just ugly in comparison... :)
But that's the beauty of toll-free bridging; you can use NSArray or
CFArray as you please. I think Michael Ash was merely pointing out
that you could take this approach with CFArray, but not that you
necessarily should. NSArray does the job just as well.
Michael Ash wrote:
On Wed, Apr 16, 2008 at 1:20 PM, John Stiles <email@hidden>
wrote:
The difference is, in STL, if you want an array where you can
remove from
the beginning, you would never use vector<> anyway. You'd use
deque<>, which
has different tradeoffs and allows fast removal of elements from the
beginning of the array. CoreFoundation doesn't let you choose and
instead it
just changes which algorithms it uses as the size of the array
grows past a
certain point, which to me is just weird. It doesn't seem like a
great
design to me. If you wanted to say one good thing about it,
though...
CFArray may never give you the best performance, but it will
probably also
prevent you from getting worst-case performance if you write really
poorly-designed algorithms.
The real difference is that they provide different concepts. STL
provides data structures, CF and Foundation provide containers. You
generally know how STL data structures are implemented and they have
performance guarantees which are pretty ironclad. CF collections are
considerably more vague about both implementation and performance.
With STL you can choose exactly how you want your stuff to be stored.
With CF, you generally choose how you want to *access* your data, and
leave the rest up to the implementation. If you want an ordered
collection, you just choose a CFArray and you can generally assume
that the performance will be decent. Since most such uses are not
performance critical, the ability to save programmer time by not
having to make a choice is generally a good tradeoff.
The nice thing about CF is that, thanks to toll-free bridging, if
you've used a CFArray everywhere and it turns out that your
particular
access pattern isn't fast enough with the built-in implementation,
you
can easily write a replacement (perhaps using STL on the back end)
and
drop it in without changing any code other than the bit that
instantiates it.
Interestingly, CFBinaryHeap doesn't fit into this at all. It all but
advertises exactly how it's implemented inside, provides tight
performance guarantees to match, and has no bridging so you can't
provide your own implementation.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden