On Fri, Mar 21, 2008 at 4:51 PM, John Stiles <[EMAIL PROTECTED]> wrote: > It's fine that you are uncomfortable with STL, but there's nothing about > your results that makes me think "this doesn't build a convincing case for > the STL option." If its performance is on par, then it's a highly convincing > case. std::map actually does more than NSDictionary—it sorts its entries > instead of keeping them in random order.
And if said capability were relevant to the problem at hand then that would be an advantage, but it's not so it's not. The thing that didn't make a convincing case for the STL option was being informed that a comparable amount of work took, using first-pass code, over one minute to execute, and that this could be brought down to reasonable levels only through a fair amount of profiling and compiler twiddling. The post to which I replied described a laborious process of implementing code using the STL and then optimizing it only to get results which I would have expected using naive code. My own results reveal that it's easy to get good performance out of the STL in my case. Presumably my compiler isn't sucking as hard, or the work I'm giving it is easier. > Also, it copies its keys instead of > just keeping a reference to them, which is also more work—it would be a much > fairer test if you used std::string* pointers for your keys and values > instead of std::string objects, but it'd also be a little more work since > you'd need a custom comparator and you'd need to consider memory management > (which boost smart pointers apparently can manage pretty well). I put roughly equal amounts of work into both tests. Of course any code can be further optimized with more work. My point is that you generally don't need to. The code to create an NSMutableDictionary and insert my keys and values into it is literally three lines of code, took about that many seconds to write, and still resulted in very good performance. > YMMV, but I like the capabilities of the STL and I think it's a pretty > powerful tool to have in one's toolbox. Not that I think you should be > forced to use it—feel free to use Foundation classes if you like them > better—but don't let bias stand in the way of reasonable comparisons. You say that as if to imply that I have been letting bias stand in the way of reasonable comparisons. Could you please point out where you think I've done that? The one place where I actually allowed my personal distaste for it to enter my post, it was explicitly stated as being my own personal preference and nothing more. On a completely unrelated note, whatever it is that your mail program is doing to indicate quoting renders gmail completely unable to properly quote the quoted portions of your post. Everything just ends up in one big blob. 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
