C++ Truths

Ever since C++ adopted lambda expressions, many have stumbled upon the question whether they can be recursive. IMO, if an anonymous function needs to call itself why not create a named function/functor in the first place? But I'm not here today to argue whether it is a good or bad design. So here it is: the most common way to create a recursive lambda in C++11. void test() { std::function<int(int)> fib = [&fib](int n) { return (n <= 2)? 1 : fib(n-1) + fib(n-2); }; } The way it works is quite interesting. First, I created a std::function object, fib, and captured that in the lambda by reference. When the lambda captures fib, it is uninitialized because nothing has been assigned to it yet. The compiler knows the type of fib so it does not complain. It happily creates a closure with an uninitialized std::function. Right after that, it assigns the closure to the fib object so it gets initialized. Therefore, the reference inside lambda also works automatical...

Lot has been said about effectively using move-semantics, such as return-by-value and pass sink arguments by-value to constructors (and move later). Dust seems to be settling on those issues because I see some evidence building up to support that. Not much has been said (I think) about using move-semantics for a collection of objects, however. I mean moving objects from one type of STL container to another and also moving elements from std::initializer_list. Moving STL Containers of the same type This one is simple. STL containers provide the necessary move operations: move-constructor and move-assign operator. So moving an entire vector<T> to another is pretty straight forward. But that is only one of several ways to construct a vector<T>. How about move constructing a std::vector from a vector with custom allocators? Or for that matter, from a std::list or a std::set? Moving objects from one type of STL container to another The classic way of copying object...

Slides of my Silicon Valley Code Camp (2013) talk are now available . If you attended this session in person please evaluate it. I take feedback/comments seriously! Overloading in Overdrive: A Generic Data-Centric Messaging Library for DDS from Sumant Tambe Abstract: When it comes to sending data across a network, applications send either binary or self-describing data (XML). Both approaches have merits. Data Distribution Service (DDS) combines the best of both in what’s called “data-centric messaging”. DDS shares the type description once, upfront, and later on sends binary data that meets the type description. You typically use IDL or XSD to specify the types and run them through a code generator for type-safe wrapper APIs for your application in your programming language. Simple and fast! As it turns out, however, C++11 bends the rules once again. In this presentation you will learn about a template-based C++11 messaging library that gives the DDS code generator a run f...

You probably already know that there are 21 ways of passing parameters to a C++11 function! In case you lost the count somewhere, lets count one more time: 4 variations of pass-by pointer (i.e., const, volatile, const volatile, and none i.e., no cv-qualifiers), 4 variations of pass-by reference (ditto here), 4 variations of pass-by value (ditto here too), 4 ways of passing an argument as an rvalue reference (ditto here too! But seriously, you don't want to be around people who write cv-qualified pass-by rvalue reference arguments), std::initializer_list (ditto here too! and at this point it is ok to browse away from this page), and finally, pass-by universal reference (more formally, perfect forwarding ... T&& ... I think universal references deserve their own spot in this overcrowded VIP lounge because they are really special and they don't have 4 variations). So that makes it 21. So you are still with me, hmm... You seem to tolerate me. So I'm going to submit...

I'm not the only one who agrees that C++ is the awesomest language for network programming . Raw network programming, however, is very low-level and leads to many distractions that reduce productivity. Networking middlewares provide higher-level network programming models while taking care of many accidental complexities that would otherwise likely to plague your distributed system. One such standards-based networking middleware is Data Distribution Service (DDS) and now there is a modern C++ binding for programming high-performance distributed real-time systems using DDS. The API is now finalized by the Object Management Group (OMG) and is known as the DDS-PSM-Cxx standard. I have two upcoming talks on the DDS-PSM-Cxx. One is in the San Francisco Bay Area and another in Aspen (Yes, C++ Now'13!) . Find out what DDS-PSM-Cxx is about and what will be covered in the talks in this new blog post on  DDS Programming using Modern C++ .

Happy New Year!! Many projects use libraries developed by different teams, organizations, and open-source communities. It is not rare to see one project using dozens of external libraries where some libraries use return codes for reporting errors and others use exceptions.  When you find yourself in such a mix, what is the best way forward as far as error handling is concerned? Should you mix return codes and exceptions freely in your code? Should you choose one particular scheme over the other?  Issues like this are faced by the users of the RTI Connext Request/Reply API, which I helped create. Visit this new blog post on Mixing Return Codes and Exceptions in C++ for my 2 cents.