Let\u00e2\u20ac\u2122s say we\u00e2\u20ac\u2122ve loaded a database table into memory and now we want to do some work with it. I\u00e2\u20ac\u2122m imagining a case where we\u00e2\u20ac\u2122ve selected a small subset of records from an enormous table (i.e.\u00c2\u00a0it wasn\u00e2\u20ac\u2122t cheap to fetch) and we want to pull records that meet particular conditions from our subset. Let\u00e2\u20ac\u2122s say it\u00e2\u20ac\u2122s customer transaction records, tens from millions, now we want to display them in various ways in a UI. We\u00e2\u20ac\u2122d rather not increase load on the database for these UI manipulations, so we\u00e2\u20ac\u2122re doing them locally in our client. (I appreciate that I\u00e2\u20ac\u2122m contriving a situation to hang the following examples around)<\/p>\n
The subset of records we\u00e2\u20ac\u2122re working with will be represented by a Fairly typical. I\u00e2\u20ac\u2122ve purposely split the search into two loops, one for each predicate (a predicate just being a fancy word for any object\/function that can be tested for boolean response on a given input).<\/p>\n Whenever you find yourself looping through a container, your first thought should be to reach for one of the C++ algorithms to replace your loop. We\u00e2\u20ac\u2122ll be looking at one in particular here, The proviso is that the output iterator must be able to cope with allocating new memory when it is assigned to and incremented. Magic; Let\u00e2\u20ac\u2122s rewrite using It\u00e2\u20ac\u2122s arguable whether this is actually an improvement. It\u00e2\u20ac\u2122s certainly not reduced the number of lines of code enough to be considered simpler; and worse it\u00e2\u20ac\u2122s separated the predicate definitions from their usage. If we\u00e2\u20ac\u2122re reading this code we have now to stop when we reach the Let\u00e2\u20ac\u2122s take an aside. What is<\/em> a function? Disregarding how it\u00e2\u20ac\u2122s implemented, from our point of view as a user of the language, a function is a reference of a type that supports using the unary operator The answer is: none. The default implementation of This might not be:<\/p>\n The times it isn\u00e2\u20ac\u2122t illegal is when we have done this:<\/p>\n Objects of this form are often called function objects<\/em> or functors<\/em>. They\u00e2\u20ac\u2122re objects that \u00e2\u20ac\u0153look like\u00e2\u20ac\u009d functions. With this in mind, let\u00e2\u20ac\u2122s make another change to our filter function:<\/p>\n Note that the You might now be thinking, \u00e2\u20ac\u0153this is even worse, it\u00e2\u20ac\u2122s even more complicated than it was\u00e2\u20ac\u009d. Yes, it is; and in C++98 and in this particular case, what I\u00e2\u20ac\u2122ve done here wouldn\u00e2\u20ac\u2122t be justified. I\u00e2\u20ac\u2122ll return to this later, let it slide temporarily. For now, I\u00e2\u20ac\u2122d like to take a detour to show why this particular construction can be made to be useful.<\/p>\n What if we were searching with a predicate more complicated than a simple boolean? Let\u00e2\u20ac\u2122s say we want to filter the transactions so that we get all those above five pounds and all those below zero (i.e.\u00c2\u00a0refunds).<\/p>\n We\u00e2\u20ac\u2122ve gone to all the effort of writing a class to test for greater-than-5. It\u00e2\u20ac\u2122s so specific in purpose that it\u00e2\u20ac\u2122s unlikely it\u00e2\u20ac\u2122ll be needed anywhere else. The compiler will almost certainly optimise the class and call away, so it\u00e2\u20ac\u2122s unlikely to have a runtime cost, but it has a think-time cost. Why bother? The answer is that we wouldn\u00e2\u20ac\u2122t; but with one small change we can suddenly make it worth the bother, and reveal the key power of functors. The key change is to add a constructor. For clarity, I\u00e2\u20ac\u2122ll just do the greater-than-5 version\u00e2\u20ac\u00a6<\/p>\n Look carefully at the magic contained here. This is not a practical example, I can\u00e2\u20ac\u2122t think of a time you would use this exact form, but it demonstrates the principle. While we\u00e2\u20ac\u2122ve, hopefully, now shown how the extra complexity can be useful and worth having it would be nice if we could get it to be a little less verbose. With C++98 we were stuck. With C++11, we have a new syntax that allows just that: lambdas.<\/p>\n In most respects we\u00e2\u20ac\u2122ve already seen lambdas. They are, in operation, exactly like one of the functors we\u00e2\u20ac\u2122ve already seen. Lambdas are simply syntactic sugar to make it possible to define an anonymous functor inline.<\/p>\n Remember our first objection to splitting the predicates into their own functions? That we made it necessary to break off our reading of the The trigger is the \u00e2\u20ac\u0153 The body of the lambda is the body of the One final piece in the puzzle: just as we were able to add parameters to our functors, we can add parameters to our lambda. There would be little point in using a literal, as we did in example #5<\/em>, we can just write that literal in the lambda body. However, it can be useful to do what\u00e2\u20ac\u2122s called variable capture<\/em>. Let\u00e2\u20ac\u2122s consider a slightly different filter function, that itself takes a parameter.<\/p>\n This will fail. The lambda body is not considered part of the scope of The There are some additional syntax features of lambdas, but you can simply look them up<\/a>. One that\u00e2\u20ac\u2122s particularly worth bearing in mind is the ability to pass Let\u00e2\u20ac\u2122s say we\u00e2\u20ac\u2122ve loaded a database table into memory and now we want to do some work with it. I\u00e2\u20ac\u2122m imagining a case where we\u00e2\u20ac\u2122ve selected a small subset of records from an enormous table (i.e.\u00c2\u00a0it wasn\u00e2\u20ac\u2122t cheap to fetch) and we want to pull records that meet particular conditions from our subset. Let\u00e2\u20ac\u2122s say\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[66,82,95,6],"_links":{"self":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1156"}],"collection":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1156"}],"version-history":[{"count":6,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1156\/revisions"}],"predecessor-version":[{"id":1179,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1156\/revisions\/1179"}],"wp:attachment":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1156"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1156"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1156"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}list<TTransactionRecord><\/code> object, CustomerTransactions<\/code>. Let\u00e2\u20ac\u2122s say that we want this filtered into two lists \u00e2\u20ac\u201c all the debits and all the credits. Here\u00e2\u20ac\u2122s a first pass:<\/p>\n\/\/ Example #1<\/span>\nvoid<\/span> filterTransactions() {\n list<TTransactionRecord> CustomerTransactions;\n \/\/ Expensive database read -- do this once<\/span>\n CustomerTransactions = dbFetchCustomerTransactions(CUSTOMER_ID);\n\n list<TTransactionRecord> TransactionDebits;\n list<TTransactionRecord> TransactionCredits;\n\n \/\/ Filter for our needs locally<\/span>\n for<\/span>( const<\/span> auto<\/span> &transaction : CustomerTransactions ) {\n \/\/ Predicate #1<\/span>\n if<\/span>( transaction.isDebit() ) {\n TransactionDebits.push_back(transaction);\n }\n }\n for<\/span>( const<\/span> auto<\/span> &transaction : CustomerTransactions ) {\n \/\/ Predicate #2<\/span>\n if<\/span>( transaction.isCredit() ) {\n TransactionCredits.push_back(transaction);\n }\n }\n}<\/code><\/pre>\ncopy_if()<\/code>. It\u00e2\u20ac\u2122s used like this:<\/p>\n #include <algorithm><\/span>\n \/\/ ...<\/span>\n copy_if( input.cbegin(), input.cend(), output.begin(), PREDICATE );<\/code><\/pre>\nvector<><\/code> in particular does not support that and will SEGFAULT if you use it as above. The STL has got you covered though. We replace the simple output iterator with a smart iterator:<\/p>\n #include <algorithm><\/span>\n #include <iterator><\/span>\n \/\/ ...<\/span>\n copy_if( input.cbegin(), input.cend(), back_inserter(output), PREDICATE );<\/code><\/pre>\nback_inserter()<\/code> creates an iterator that converts assignments to, effectively, push_back()<\/code>, which vector<><\/code> will handle regardless of the memory it already has allocated.<\/p>\nPREDICATE<\/code> is the special part here. Before the output is assigned to, the element in question is passed to the function referenced by PREDICATE, which gives a boolean response. Essentially it provides the \u00e2\u20ac\u0153if\u00e2\u20ac\u009d part of our loop.<\/p>\ncopy_if()<\/code>.<\/p>\n\/\/ Example #2<\/span>\nbool customerDebitPredicate( const<\/span> TTransactionRecord &O ) {\n return<\/span> O.isDebit();\n}\nbool customerDebitPredicate( const<\/span> TTransactionRecord &O ) {\n return<\/span> O.isCredit();\n}\n\nvoid<\/span> filterTransactions() {\n list<TTransactionRecord> CustomerTransactions;\n CustomerTransactions = dbFetchCustomerTransactions(CUSTOMER_ID);\n\n list<TTransactionRecord> TransactionDebits;\n list<TTransactionRecord> TransactionCredits;\n\n copy_if(CustomerTransactions.cbegin(), CustomerTransactions.end(),\n back_inserter(TransactionDebits), customerDebitPredicate);\n copy_if(CustomerTransactions.cbegin(), CustomerTransactions.end(),\n back_inserter(TransactionCredits), customerCreditPredicate);\n}<\/code><\/pre>\ncopy_if()<\/code> to go and see what the customerDebitPredicate()<\/code> actually does; and it\u00e2\u20ac\u2122s not immediately obvious at that point that customerDebitPredicate<\/code> is a function. However, we\u00e2\u20ac\u2122re not done yet, this is only a step along the way, so let\u00e2\u20ac\u2122s hold our objections for now.<\/p>\n()<\/code> on it. Compare that with say, the unary postincrement operator ++<\/code>. What, fundamentally, is the difference between these two constructs?<\/p>\n x();\n y++;<\/code><\/pre>\noperator()()<\/code> (for that is the C++ way of naming the operator we\u00e2\u20ac\u2122re talking about) is to call the reference (for those types that are callable \u00e2\u20ac\u201c function references). C++ grants us the ability to add support for operator()()<\/code> to our own types though, so where this is illegal:<\/p>\n int<\/span> x;\n x();<\/code><\/pre>\n TCustomType x;\n x();<\/code><\/pre>\nclass TCustomType {\n public:\n void<\/span> operator()() {\n \/\/ ... whatever ...<\/span>\n }\n}<\/code><\/pre>\n\/\/ Example #3<\/span>\nclass TTransactionDebitPredicate {\n public:\n bool operator()( const<\/span> TTransactionRecord &O ) { return<\/span> O.isDebit(); }\n}\nclass TTransactionCreditPredicate {\n public:\n bool operator()( const<\/span> TTransactionRecord &O ) { return<\/span> O.isCredit(); }\n}\n\nvoid<\/span> filterTransactions() {\n list<TTransactionRecord> CustomerTransactions;\n CustomerTransactions = dbFetchCustomerTransactions(CUSTOMER_ID);\n\n list<TTransactionRecord> TransactionDebits;\n list<TTransactionRecord> TransactionCredits;\n\n copy_if(CustomerTransactions.cbegin(), CustomerTransactions.end(),\n back_inserter(TransactionDebits), TTransactionDebitPredicate() );\n copy_if(CustomerTransactions.cbegin(), CustomerTransactions.end(),\n back_inserter(TransactionCredits), TTransactionCreditPredicate() );\n}<\/code><\/pre>\ncopy_if()<\/code> calls have changed, we have to pass instantiations (albeit temporary ones) of the predicate objects, as the operator()()<\/code> implementations are not<\/em> static, they must be called on an instance.<\/p>\n\/\/ Example #4<\/span>\nclass TTransactionBigPredicate {\n public:\n bool operator()( const<\/span> TTransactionRecord &O ) {\n return<\/span> O.value() > 5<\/span>;\n }\n}\nclass TTransactionSmallPredicate {\n public:\n bool operator()( const<\/span> TTransactionRecord &O ) {\n return<\/span> O.value() < 0<\/span>;\n }\n}\n\nvoid<\/span> filterTransactions() {\n list<TTransactionRecord> CustomerTransactions;\n CustomerTransactions = dbFetchCustomerTransactions(CUSTOMER_ID);\n\n list<TTransactionRecord> TransactionBigs;\n list<TTransactionRecord> TransactionSmalls;\n\n copy_if(CustomerTransactions.cbegin(), CustomerTransactions.end(),\n back_inserter(TransactionBigs), TTransactionBigPredicate() );\n copy_if(CustomerTransactions.cbegin(), CustomerTransactions.end(),\n back_inserter(TransactionSmalls), TTransactionSmallPredicate() );\n}<\/code><\/pre>\n\/\/ Example #5<\/span>\nclass TTransactionGreaterThanPredicate {\n public:\n TTransactionGreaterThanPredicate(int<\/span> t) : mThreshold(t) {}\n bool operator()( const<\/span> TTransactionRecord &O ) {\n return<\/span> O.value() > mThreshold;\n }\n protected:\n int<\/span> mThreshold;\n}\n\nvoid<\/span> filterTransactions() {\n list<TTransactionRecord> CustomerTransactions;\n CustomerTransactions = dbFetchCustomerTransactions(CUSTOMER_ID);\n\n list<TTransactionRecord> TransactionBigs;\n\n copy_if(CustomerTransactions.cbegin(), CustomerTransactions.end(),\n back_inserter(TransactionBigs), TTransactionGreaterThanPredicate(5<\/span>) );\n}<\/code><\/pre>\ncopy_if()<\/code> requires a function with a very particular function signature: bool()(const TTransactionRecord &O)<\/code>. We cannot change that signature, so we cannot parameterise that call to suit us. However, by passing a functor that can supply a function of that signature, we are able to parameterise the functor however we like via its constructor. Here we\u00e2\u20ac\u2122ve used a simple literal, but it could be anything \u00e2\u20ac\u201c a reference to another transaction say; an object that reads from a UI settings box; one that fetches a threshold from a file. We can add an arbitrary level of complexity to the predicate without having to change the search function one bit, copy_if()<\/code> remains the same. This can be incredibly powerful. Even more so once you realise that you can even template the functor.<\/p>\n\/\/ Example #6<\/span>\ntemplate<typename T>\nclass TGreaterThanPredicate {\n public:\n TGreaterThanPredicate(int<\/span> t) : mThreshold(t) {}\n bool operator()( const<\/span> T &O ) {\n return<\/span> O.value() > mThreshold;\n }\n protected:\n int<\/span> mThreshold;\n}\n\nvoid<\/span> filterTransactions() {\n list<TTransactionRecord> CustomerTransactions;\n CustomerTransactions = dbFetchCustomerTransactions(CUSTOMER_ID);\n\n list<TTransactionRecord> TransactionBigs;\n\n copy_if(CustomerTransactions.cbegin(), CustomerTransactions.end(),\n back_inserter(TransactionBigs),\n TGreaterThanPredicate<TTransactionRecord>(5<\/span>) );\n}<\/code><\/pre>\nTGreaterThanPredicate<><\/code> will supply \u00e2\u20ac\u02dcgreater than\u00e2\u20ac\u2122 functionality for any class that supplies a .value()<\/code> member.<\/p>\ncopy_if()<\/code> to read the predicate definition? Lambdas remove that necessity. The syntax for defining a (simple) lambda inline is this:<\/p>\nauto<\/span> refToLamba = [](bool param){ return<\/span> param; };<\/code><\/pre>\n[]<\/code>\u00e2\u20ac\u009d, and you then write as you would a function definition, with whatever parameters you wish (those parameters will usually be determined by the caller you\u00e2\u20ac\u2122re passing the lambda to). Let\u00e2\u20ac\u2122s rewrite example #4<\/em> with lambdas to show that happening:<\/p>\n\/\/ Example #7<\/span>\nvoid<\/span> filterTransactions() {\n list<TTransactionRecord> CustomerTransactions;\n CustomerTransactions = dbFetchCustomerTransactions(CUSTOMER_ID);\n\n list<TTransactionRecord> TransactionBigs;\n list<TTransactionRecord> TransactionSmalls;\n\n copy_if(CustomerTransactions.cbegin(), CustomerTransactions.end(),\n back_inserter(TransactionBigs),\n [](const<\/span> TTransactionRecord &O){ return<\/span> O.isDebit();} );\n copy_if(CustomerTransactions.cbegin(), CustomerTransactions.end(),\n back_inserter(TransactionSmalls),\n [](const<\/span> TTransactionRecord &O){ return<\/span> O.isDebit();} );\n}<\/code><\/pre>\noperator()(const TTransactionRecord &O)<\/code> that we wrote in example #4<\/em>. The compiler effectively generates that functor as a temporary when we use the lambda syntax; and we\u00e2\u20ac\u2122re now back to being able to see the predicate inline, but also not having had to do any of the looping work ourselves.<\/p>\n\/\/ Example #8<\/span>\nvoid<\/span> filterTransactions(int<\/span> threshold) {\n list<TTransactionRecord> CustomerTransactions;\n CustomerTransactions = dbFetchCustomerTransactions(CUSTOMER_ID);\n\n list<TTransactionRecord> TransactionBigs;\n\n copy_if(CustomerTransactions.cbegin(), CustomerTransactions.end(),\n back_inserter(TransactionBigs),\n [](const<\/span> TTransactionRecord &O){ return<\/span> O.value() > threshold;} );\n}<\/code><\/pre>\nfilterTransactions()<\/code> and so has no access to the threshold<\/code> variable. What we need is the parameter to be passed as a constructor argument exactly as we did in example #5<\/em>. Lambdas fortunately have a syntax for that.<\/p>\n\/\/ Example #9<\/span>\nvoid<\/span> filterTransactions(int<\/span> threshold) {\n list<TTransactionRecord> CustomerTransactions;\n CustomerTransactions = dbFetchCustomerTransactions(CUSTOMER_ID);\n\n list<TTransactionRecord> TransactionBigs;\n\n copy_if(CustomerTransactions.cbegin(), CustomerTransactions.end(),\n back_inserter(TransactionBigs),\n [=threshold](const<\/span> TTransactionRecord &O){ return<\/span> O.value() > threshold;} );\n}<\/code><\/pre>\n[=threshold]<\/code> is the equivalent of adding an int threshold<\/code> data member to the functor, and passing it by value to the functor constructor (just like example #5<\/em>). Lambdas offer additional syntax that let us pass variables in the enclosing scope by reference<\/em> instead of by value. That means we can modify them. That gives us quite a powerful facility. For example:<\/p>\n\/\/ Example #10<\/span>\nvoid<\/span> filterTransactions(int<\/span> threshold) {\n list<TTransactionRecord> CustomerTransactions;\n CustomerTransactions = dbFetchCustomerTransactions(CUSTOMER_ID);\n\n list<TTransactionRecord> TransactionBigs;\n\n int<\/span> rejectCount = 0<\/span>;\n copy_if(CustomerTransactions.cbegin(), CustomerTransactions.end(),\n back_inserter(TransactionBigs),\n [=threshold, &rejectCount](const<\/span> TTransactionRecord &O) {\n if<\/span>( O.value() > threshold ) {\n return<\/span> true;\n }\n rejectCount++;\n return<\/span> false;\n });\n \/\/ rejectCount now tells us how many records _didn't_ match the<\/span>\n \/\/ predicate<\/span>\n}<\/code><\/pre>\nthis<\/code> as a lambda parameter. That means you can get access to more than just the enclosing scope variables, you can get access to the enclosing object.<\/p>\n","protected":false},"excerpt":{"rendered":"