I love foreach. What I really mean is that I really like dead-simple ways to iterate over the items in a container, one at a time. It goes beyond syntactic sugar; making errors harder to write, and easier to spot.<\/p>\n
I’m using the term “foreach”, because the first time I realized the utility of simple iteration was seeing Michael Tsai’s foreach macro<\/a>. I instantly fell in love with the ‘keyword’, because it greatly simplifies iterating over items in a Cocoa container. My reaction was so strong, because the (then current) Cocoa iteration idiom I was using was so bad. As Jonathan ‘Wolf’ Rentzsch says:<\/a><\/p>\n \nI have a number of issues with enumeration in Cocoa\/ObjC. Indeed, I have a problem with every one<\/b> of the three lines necessary in the standard idiom. It even goes beyond that — I have an problem with the very fact it’s three lines of code<\/b> versus one<\/b>.\n<\/p><\/blockquote>\n Objective-C 2.0 (Leopard and later) introduced Fast Enumeration<\/a>. It’s a better way of handling enumeration then Michael Tsai’s macro, but if you are stuck using Objective-C 1.0, then I highly recommend using his foreach<\/a> macro.<\/p>\n I do not like the C++ stl for_each<\/a> idiom. It’s not simple enough.<\/p>\n To explain what’s wrong with The most obvious benefits of a foreach is that it’s less code, easier to write, and less work to read. Implemented correctly, it also makes bugs harder to write — mostly because it minimizes side effects in the loop construct. For example, do you see the bug in the following code?<\/p>\n I didn’t; and it’s kind of a trick question. Using BOOST_FOREACH<\/a> avoids the problem: Loops are a staple of programming. Simplifying and error-proofing the most common kind of loop is a huge productivity win. foreach regardless <\/a> of<\/a> it’s<\/a> flavor<\/a>, is<\/a> worth a try.<\/p>\n","protected":false},"excerpt":{"rendered":" I love foreach. What I really mean is that I really like dead-simple ways to iterate over the items in a container, one at a time. It goes beyond syntactic sugar; making errors harder to write, and easier to spot. I’m using the term “foreach”, because the first time I realized the utility of simple […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7,6,12,5,4,11],"tags":[],"class_list":["post-23","post","type-post","status-publish","format-standard","hentry","category-c","category-cocoa","category-design","category-objective-c","category-programming","category-research"],"_links":{"self":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/23","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/comments?post=23"}],"version-history":[{"count":0,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/23\/revisions"}],"wp:attachment":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/media?parent=23"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/categories?post=23"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/tags?post=23"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}for_each<\/code> I should explain what a “foreach” should<\/em> look like. It should be a two-argument construct: “foreach (item, container)<\/code>“, and no more. container<\/code> should be evaluated only once. Syntax details aren’t terribly important, as long as they make sense.
\nforeach(child, naughtyList)<\/code>
\niterate(child, naughtyList)<\/code>
\nForEach(String child, naughtyList)<\/code>
\nfor child in naughyList:<\/code><\/a>
\nfor(NSString *child in naughtyList)<\/code><\/a>
\nAre all fine constructs.<\/p>\nfor( list<shared_ptr<const Media> >::iterator it = selectedMedias->selectedMediaList().begin(); it != selectedMedias->selectedMediaList().end(); ++it )<\/code><\/p>\n->selectedMediaList()<\/code> isn’t an accessor function — it constructs a new list every time it is called. So selectedMediaList() != selectedMediaList()<\/code> because it returns a different list each time. The loop never terminates because it<\/code> will never equal end()<\/code>, since it is the end of a different<\/em> list. But you have no way of knowing this without knowing details of what selectedMediaList()<\/code> does.<\/p>\n
\nBOOST_FOREACH<\/a>(shared_ptr<const CSMediaLib::Media> media, selectedMedias->selectedMediaList())<\/code>
\nworks regardless of how selectedMediaList()<\/code> is implemented, because it is only evaluated once. It’s also easier to write, and to read. I haven’t used BOOST_FOREACH<\/a> much, but it’s been totally positive so far. (Yes, the name is ugly, but that’s not important).<\/p>\n