{"id":1541,"date":"2016-06-20T07:23:44","date_gmt":"2016-06-20T06:23:44","guid":{"rendered":"http:\/\/netrix.org.pl\/?p=1541"},"modified":"2016-06-20T07:23:44","modified_gmt":"2016-06-20T06:23:44","slug":"range-based-for-loop-vs-stdtransform","status":"publish","type":"post","link":"https:\/\/netrix.org.pl\/index.php\/2016\/06\/20\/range-based-for-loop-vs-stdtransform\/","title":{"rendered":"Range-based for loop vs std::transform"},"content":{"rendered":"

Some time ago, while doing some code review in work I came across the problem whether the loop in the code I was reviewing should be expressed with std::for_each<\/em>, std::transform<\/em> or range-based for loop<\/em>. The initial code looked pretty much like this:<\/p>\n

std::vector destination;\r\ndestination.reserve(source.size());\r\n\r\nstd::for_each(std::begin(source), std::end(source), \r\n              [&destination](auto const& p_value)\r\n{\r\n    destination.push_back(SomeStruct{p_value.a, p_value.b, p_value.c});\r\n});\r\n<\/pre>\n
The first things that come to my mind when I see such code are “Why are you using std::for_each<\/em>? Shouldn’t you use range-based for<\/em> loop?” Or maybe there should be a std::transform<\/em>?” Let’s consider those three things:<\/p>\n
std::for_each<\/em><\/h4>\n
This is an algorithm from standard library that represents standard for loop that goes over a range defined by begin and end iterator and runs given functor or function. An example of usage is presented above. It utilizes lambda expression that invokes push_back on a std::vector to add elements.<\/p>\n
range-based for<\/em><\/h4>\n
Given algorithm can be easily converted to this new form of loop (introduced in C++11).<\/p>\n
\r\nstd::vector destination;\r\ndestination.reserve(source.size());\r\n\r\nfor(auto const& p_value : source) \r\n{\r\n    destination.push_back(SomeStruct{p_value.a, p_value.b, p_value.c});\r\n};\r\n<\/pre>\n
This is the same algorithm but in much clearer and less noisy form.<\/p>\n
std::transform<\/em><\/h4>\n
Another considered algorithm is std::transform<\/em> that is supposed to be used (as the name says) to transform one structure to another. Let’s convert given code to utilize this algorithm.<\/p>\n
std::vector destination;\r\ndestination.reserve(source.size());\r\n\r\nstd::transform(std::begin(source), std::end(source), std::back_inserter(destination),\r\n              [](auto const& p_value)\r\n{\r\n    return SomeStruct{p_value.a, p_value.b, p_value.c};\r\n});<\/pre>\n
It looks pretty much like std::for_each<\/em>. The difference is in the name, the third argument and that the lambda returns new value instead of inserting in into the new container.<\/p>\n
To be honest, when I have to choose between those versions I would choose std::transform<\/em> because of its explicitness. This algorithm just says what is done. It gets one array and transforms it into another. std::for_each<\/em> and range-based-for<\/em> are just simple loops with no more special meaning than “run this function over this array”. From the last two if I had to choose one, then I would prefer range-based-for<\/em> since its very clean form of loop over an array (no additional noise in form of lambda or std::begin\/std::end<\/em>).<\/p>\n
But…<\/h4>\n
Since we are considering C++11 there’s one more thing to consider when inserting elements into std::vector<\/em> – emplace_back<\/em>. If we have a class with constructor and emplace_back<\/em> then situation changes, because emplace_back<\/em> allows us to create objects right inside the vector’s memory. In that case using std::transform<\/em> doesn’t allow such operation because it requires copy (inside std::back_inserter<\/em>). <\/p>\n
Let’s take look at the code with all scenarios:<\/p>\n
\r\n#include \r\n#include \r\n#include \r\n\r\nstruct TestStruct\r\n{\r\n    TestStruct(int a, std::string b)\r\n        : m_a(a)\r\n        , m_b(b)\r\n    {\r\n        std::cout << \">> Constructor: a=\" << m_a << \", b=\" << m_b << std::endl;\r\n    }\r\n\r\n    TestStruct(TestStruct const& src)\r\n        : m_a(src.m_a)\r\n        , m_b(src.m_b)\r\n    {\r\n        std::cout << \">> Copy Constructor: a=\" << m_a << \", b=\" << m_b << std::endl;\r\n    }\r\n\r\n    TestStruct(TestStruct && src)\r\n        : m_a(src.m_a)\r\n        , m_b(std::move(src.m_b))\r\n    {\r\n        std::cout << \">> Move Constructor: a=\" << m_a << \", b=\" << m_b << std::endl;\r\n    }\r\n\r\n    ~TestStruct()\r\n    {\r\n        std::cout << \">> Destructor: a=\" << m_a << \", b=\" << m_b << std::endl;\r\n    }\r\n\r\nprivate:\r\n    int m_a;\r\n    std::string m_b;\r\n};\r\n\r\nstruct InputStruct\r\n{\r\n    int a;\r\n    std::string b;\r\n};\r\n\r\nusing namespace std;\r\n\r\nint main(int argc, char *argv[])\r\n{\r\n    InputStruct input[] = {\r\n        { 1, \"one\" },\r\n        { 2, \"two\" },\r\n    };\r\n\r\n    std::cout << \"std::for_each:\" << std::endl;\r\n\r\n    std::vector va;\r\n    va.reserve(std::end(input) - std::begin(input));\r\n    std::for_each(std::begin(input), std::end(input),\r\n                  [&va](auto const& p_in)\r\n    {\r\n        va.push_back(TestStruct{p_in.a, p_in.b});\r\n    });\r\n\r\n    std::cout << \"\\nrange-based-for:\" << std::endl;\r\n\r\n    std::vector vb;\r\n    va.reserve(std::end(input) - std::begin(input));\r\n    for(auto const& p_in : input)\r\n    {\r\n        vb.push_back(TestStruct{p_in.a, p_in.b});\r\n    }\r\n\r\n    std::cout << \"\\nstd::transform:\" << std::endl;\r\n    std::vector vc;\r\n    vc.reserve(std::end(input) - std::begin(input));\r\n    std::transform(std::begin(input), std::end(input), std::back_inserter(vc),\r\n                  [](auto const& p_in)\r\n    {\r\n        return TestStruct{p_in.a, p_in.b};\r\n    });\r\n\r\n    std::cout << \"\\nrange-based-for + emplace_back:\" << std::endl;\r\n\r\n    std::vector vd;\r\n    vd.reserve(std::end(input) - std::begin(input));\r\n    for(auto const& p_in : input)\r\n    {\r\n        vd.emplace_back(p_in.a, p_in.b);\r\n    }\r\n\r\n    std::cout << \"\\n\\nDestruction of all items:\" << std::endl;\r\n}\r\n\r\n<\/pre>\n
The output is as follows:<\/p>\n
std::for_each:\r\n>> Constructor: a=1, b=one\r\n>> Move Constructor: a=1, b=one\r\n>> Destructor: a=1, b=\r\n>> Constructor: a=2, b=two\r\n>> Move Constructor: a=2, b=two\r\n>> Destructor: a=2, b=\r\n\r\nrange-based-for:\r\n>> Constructor: a=1, b=one\r\n>> Move Constructor: a=1, b=one\r\n>> Destructor: a=1, b=\r\n>> Constructor: a=2, b=two\r\n>> Move Constructor: a=2, b=two\r\n>> Destructor: a=2, b=\r\n\r\nstd::transform:\r\n>> Constructor: a=1, b=one\r\n>> Move Constructor: a=1, b=one\r\n>> Destructor: a=1, b=\r\n>> Constructor: a=2, b=two\r\n>> Move Constructor: a=2, b=two\r\n>> Destructor: a=2, b=\r\n\r\nrange-based-for + emplace_back:\r\n>> Constructor: a=1, b=one\r\n>> Constructor: a=2, b=two\r\n\r\n\r\nDestruction of all items:\r\n>> Destructor: a=1, b=one\r\n>> Destructor: a=2, b=two\r\n>> Destructor: a=1, b=one\r\n>> Destructor: a=2, b=two\r\n>> Destructor: a=1, b=one\r\n>> Destructor: a=2, b=two\r\n>> Destructor: a=1, b=one\r\n>> Destructor: a=2, b=two\r\n<\/pre>\n
The output from the app reveals everything. The emplace_back<\/em> version produces the smallest output, just as suspected, and all other loops does exactly the same thing.<\/p>\n
What about POD?<\/h4>\n
Of course the previous version works smoothly only with classes that defines the constructor which can be used within emplace_back<\/em>. When considering POD structs that doesn't have one, the trick won't work and won't even compile. When adding POD object into vector it requires explicit use of the struct name when creating new objects that goes to the container.<\/p>\n
In such case, in my opinion, the std::transform<\/em> is the best way to express the intent.<\/p>\n","protected":false},"excerpt":{"rendered":"
Some time ago, while doing some code review in work I came across the problem whether the loop in the code I was reviewing should be expressed with std::for_each, std::transform or range-based for loop. The initial code looked pretty much like this: std::vector destination; destination.reserve(source.size()); std::for_each(std::begin(source), std::end(source), [&destination](auto const& p_value) { destination.push_back(SomeStruct{p_value.a, p_value.b, p_value.c}); }); […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[205,179,206],"_links":{"self":[{"href":"https:\/\/netrix.org.pl\/index.php\/wp-json\/wp\/v2\/posts\/1541"}],"collection":[{"href":"https:\/\/netrix.org.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/netrix.org.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/netrix.org.pl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/netrix.org.pl\/index.php\/wp-json\/wp\/v2\/comments?post=1541"}],"version-history":[{"count":14,"href":"https:\/\/netrix.org.pl\/index.php\/wp-json\/wp\/v2\/posts\/1541\/revisions"}],"predecessor-version":[{"id":1560,"href":"https:\/\/netrix.org.pl\/index.php\/wp-json\/wp\/v2\/posts\/1541\/revisions\/1560"}],"wp:attachment":[{"href":"https:\/\/netrix.org.pl\/index.php\/wp-json\/wp\/v2\/media?parent=1541"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/netrix.org.pl\/index.php\/wp-json\/wp\/v2\/categories?post=1541"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/netrix.org.pl\/index.php\/wp-json\/wp\/v2\/tags?post=1541"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}