News for hackers. Stuff that matters.
Re:Our arrays aren't (2005) by cjlarose on Friday January 23, 2015 @08:15PM (#8938425)
The author seems to criticize that the Java classes are named for how they're implemented, whereas the CoreFoundation ones are named for what they are instead. In Java, though, the convention (at least in the Collection library), is that the Interface name tells you what the thing is (List, Map, Set), and the class name tells you how it's implemented (ArrayList/LinkedList, HashMap/ConcurrentMap, HashSet/TreeSet).
Re:Our arrays aren't (2005) by divs1210 on Saturday January 24, 2015 @03:21PM (#8940853)
The author is criticizing Apple's versions, not the Java/C++ ones.
Re:Our arrays aren't (2005) by sjolsen on Friday January 23, 2015 @05:45PM (#8937837)
Nitpick: the STL is not standard C++. The containers in the standard library are listed at http://en.cppreference.com/w/cpp/container.
Re:Our arrays aren't (2005) by EpicEng on Friday January 23, 2015 @10:25PM (#8938702)
Yes, it is. Its basis was developed independently, but when people speak of the STL today, they are referring to the standard algorithms and containers.
Re:Our arrays aren't (2005) by marvy on Friday January 23, 2015 @06:28PM (#8938046)
The containers for the standard library are indeed at the link you provided. Those are traditionally referred to as STL containers. No?
Re:Our arrays aren't (2005) by sjolsen on Saturday January 24, 2015 @06:31PM (#8941472)
The STL is a product developed and maintained by SGI. If you look at the containers listed in the article and on the SGI page, you will see a different set than is present in the C++ standard library, especially if you discount the containers that weren't in the C++ standard library when the article was written.

Now, people often refer to the C++ standard library as the STL, but the author of the article was clearly confusing the STL itself with the standard library, not just the name.

Re:Our arrays aren't (2005) by cliffordcib on Friday January 23, 2015 @11:28PM (#8938829)
What's the actual data structure behind this? Is it something like the blist[1] (i.e., counted b+ tree)?

[1] https://pypi.python.org/pypi/blist/

EDIT: Nvm, the article actually links to the implementation and it seems to be an order statistics 2-3 tree: http://www.opensource.apple.com/source/CF/CF-368.18/Collecti...

Re:Our arrays aren't (2005) by nkurz on Friday January 23, 2015 @05:30PM (#8937745)
I'm a bit surprised that the graphs for the "standard" arrays are so flat. I would have guessed that there were be some cache and TLB effects. I'd be interested to see what it looks like on a modern processor, but the link to the source is dead. Please post a link if you find it.
Re:Our arrays aren't (2005) by tosh on Friday January 23, 2015 @01:40PM (#8936446)
TL;DR Everything you ever wanted to know about Objective-C's NSMutableArray
Re:Our arrays aren't (2005) by chris_wot on Friday January 23, 2015 @11:16PM (#8938805)
Your TL;DR requires me to read the article.
Re:Our arrays aren't (2005) by tosh on Monday January 26, 2015 @12:31PM (#8948272)
You are right, sorry about that, should have named it 'More descriptive title' instead of 'TL;DR'.