\nSome follow-up notes on\n\nEmulating the C# \nThe main complication that prevented us from using RAII was\nthe use of the\n\nParallel Patterns Library<\/A> (PPL)\nto express asynchronous programming in C++.¹\nThe most general pattern for asynchronous programming is that\nyou start an operation, and then specify a callback\nto be invoked when the operation completes.\nIn traditional C-style programming, this callback is\na boring function pointer, coupled with some reference\ndata so the callback has context for why it is being called back.\nC++ provides lambdas which let you express the continuation as\na callback object<\/I>,\nwhich is much more convenient since you can express the control\nflow inline instead of having tiny pieces of control flow scattered\nall over your program.\nAnd lambda capture makes it easy to express what pieces of information\nneeds to be carried forward to the continuation.\n<\/P>\n \nIf we didn’t have any asynchronous operations, then a basic RAII\nclass would do the trick:\nWhen the RAII class destructs, the cleanup operation occurs.\n(In our example, the cleanup operation is calling \nThe magical step was the\nintroduction of the not-yet-standard-but-hopefully-soon\n \nAs a result, switching to using<\/CODE> keyword in C++<\/A>,\nprimarily for the benefit of\n\npeople from reddit who stumbled into the series and\ndidn’t understand the context of the discussion<\/A>,\nbecause this was really part 6 of the series begun the previous week,\neven though it wasn’t labeled as such.\n(And the title itself was a party trick rather than a serious\nproposal.)\n<\/P>\nClose<\/CODE>.)\nThe difficulty in the asynchonous case\nis that it is cumbersome to keep carrying\nthis RAII class forward and preventing it\nfrom destructing until the entire chain of continuations has completed.\nThat’s where the ensure_<\/CODE>close<\/CODE> and\nshared_<\/CODE>close<\/CODE> classes entered the picture.\nBut you still had to remember to carry them forward.\n<\/P>\nco_await<\/CODE> keyword.\nThis\n\ntransforms the function into a state machine<\/A>,\nwhere each co_await<\/CODE> represents\nthe end of a state.\nThe current execution state is saved, and execution of the task\nsuspends.\nWhen the awaited operation completes, the execution state is\nrestored and the function resumes execution.\nThis transformation is very tedious and error-prone to perform\nby hand (especially when there are loops and branches),\nand in particular,\nit preserves RAII semantics:\nThe automatic variables created by the pre-transformed function\nbecome part of the execution state,\nand they are destructed at the “natural” time they would have\nbeen destructed prior to transformation.\n<\/P>\nco_await<\/CODE> brings us full circle\nback to plain old RAII.\nBehind the scenes, the compiler is doing the wacky transformations\nthat we tried to mimic with ensure_<\/CODE>close<\/CODE>\nand shared_<\/CODE>close<\/CODE>.\nBut co_await<\/CODE> lets us write the code in a far more natural way.\n<\/P>\n