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... :)
Michael Ash wrote:
On Wed, Apr 16, 2008 at 1:20 PM, John Stiles <[EMAIL PROTECTED]> 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 (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/jstiles%40blizzard.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
