Skip to main content


Showing posts from 2012

C++/C++11 Track @ Silicon Valley Code Camp 2012

For the first time in 7 years, 2012  Silicon Valley Code Camp will have a track dedicated to C++ and C++11 . Code Camp is a conference of developers, by developers, for developers. Attendance is free! This year, the number of attendees is expected to exceed 2200 to attend 223 sessions on a variety of topics related to software technology. Code Camp will be held @ Foothill College on Oct. 6th and 7th (weekend) in Silicon Valley. C++ is clearly one of the big things at Code Camp this year. The track has sessions on exception-safe coding, generic programming, logic programming, Windows 8 development, and the Clang compiler. There are sessions focused on C++11 too. Purely on the language side, two sessions on rvalue references, move semantics, perfect forwarding, and modern idioms of using them in your programs should whet the appetite of any C++11 programmer. On the standard library side, how about C++11 threading library! On Sunday, I'll present two sessions : "C++11 I

Perfect Forwarding of Parameter Groups in C++11

C++11 offers a great new feature called Perfect Forwarding , which is enabled via the use of rvalue references. Perfect forwarding allows a function template to pass its arguments through to another function while retaining the original lvalue/rvalue nature of the function arguments. It avoids unnecessary copying and avoids the programmer having to write multiple overloads for different combinations of lvalue and rvalue references. A class can use perfect forwarding with variadic templates to "export" all possible constructors of a member object at the parent's level. class Blob { std::vector<std::string> _v; public: template<typename... Args> Blob(Args&&... args) : _v(std::forward<Args>(args)...) { } }; int main(void) { const char * shapes[3] = { "Circle", "Triangle", "Square" }; Blob b1(5, "C++ Truths"); Blob b2(shapes, shapes+3); } The Blob class above contains a std::vecto

Rvalue references in constructor: when less is more

I've seen a recurring mistake made by well-versed C++03 programmers when they set out to use rvalue references for the first time. In fact, as it turns out, better you are at C++03, easier it is to fall in the trap of rvalue reference anti-pattern I'm gonna talk about. Consider the following C++03 class: class Book { public: Book(const std::string & title, const std::vector<std::string> & authors, const std::string & pub, size_t pub_day const std::string & pub_month, size_t pub_year) : _title(title), _authors(authors), _publisher(pub), _pub_day(pub_day), _pub_month(pub_month), _pub_year(pub_year) {} // .... // .... private: std::string _title; std::vector<std::string> _authors; std::string _publisher; size_t _pub_day; std::string _pub_month; size_t _pub_year; }; The Book class above is as dull as it can be. Now lets C++11'fy it!

Array-like access and Iterators for Homogeneous Tuples

Question often comes up whether tuples can have traditional iterators? In general, the answer is: No! They cannot. That's because tuples typically contain different types and traditional iterators, which are modeled after pointers, can not dereference to objects of multiple types. However, homogeneous tuples can have iterators. So I thought it would be a fun exercise to write one. I wonder why one would use a homogeneous tuples instead of just plain arrays. But lets do it anyways because we can. Although this exercise sounds rather naive and unnecessary, I stumbled upon two very interesting topics along the way. A need for new iterator concepts to separate the notions of element access from iterator traversal. Yes! iterators for homogeneous tuples can't be modeled accurately using conventional iterator categories. Don't believe me? Please read on... How inherited constructors may be simulated on compilers that don't support them today. From this point onward a tuple i

General-purpose Automatic Memoization for Recursive Functions in C++11

Memoization is a widely known optimization technique used primarily to speed up computer programs by having function calls avoid repeating the calculation of results for previously processed inputs. Repeated calculations are avoided by reusing previously computed results, which must be cached such that look-up is faster than recomputing. Consider a simple fibonacci program unsigned long fibonacci(unsigned n) { return (n < 2) ? n : fibonacci(n - 1) + fibonacci(n - 2); } This algorithm is a frustratingly slow way of computing the Nth fibonacci number (N starting at 0). It does a lot of redundant recomputations. But the beauty of this program is that it is really simple. To speed it up without changing its logic significantly, we could use memoization. Using some clever C++11 techniques, it is possible to memoize this function, which looks like below. unsigned long fibonacci(unsigned n) { return (n < 2) ? n : memoized_recursion(fibonacci)(n - 1) + memoized_recurs