I travel to a lot of conferences, but among the ones I like the most are Software Architect and DevWeek. I'm writing this post on the flight back home from Software Architect, where I had the pleasure of delivering a workshop and three talks. If you attended the conference, thanks a lot for coming and I hope you find the materials useful; if you haven't been to the conference, I expect to see you next year!
My first talk was an introduction to Haskell for developers with no prior experience in functional programming. For me personally, Haskell is not...
This is my second TechDays this year--I've had the pleasure of visiting the Netherlands and now also Sweden to speak at TechDays on a variety of topics. Both events had quite a special atmosphere with a lot of activity, a lot more session slots than usual at software conferences, and a great selection of international speakers (except for your humble servant, of course). Even though most talks were in languages I don't understand, I really enjoyed my time.
But I'm guessing you're here because you want to put your hands on materials from my two talks--so here they are, without...
The C++ language many of us are using today goes back more than thirty years. You might be using some “newer” features, such as templates or the standard library, which have been standardized around 1998 – the previous millennium. Since 1998, C++ has seen two major international standards – C++ 11 and C++ 14, and work is in progress on another major revision to be published in 2017.
Over the last few years, C++ developers all over the world are transitioning to the new, modern C++. It’s not just a matter of language features or library APIs. It’s a matter...
tl;dr -- when migrating from Visual C++ 2013 to Visual C++ 2015, make sure that (1) your destructors do not throw exceptions, and (2) your move constructors are marked noexcept if they do not throw exceptions.
Less than a year ago, I described some of the reasons why noexcept is an important C++ language feature that lurks in the background and waits for the right moment to bite you in the neck.
Specifically, destructors and move constructors should ideally be marked as noexcept. For move constructors, this "ideally" means there are corner cases where performance won't be optimal if you don't mark the move constructor noexcept; for destructors,...
Just a couple of months ago, I agreed to deliver eight breakout sessions and a full-day workshop at DevWeek 2015. And no, I don't have any regrets -- but it was definitely a very packed week with lots of room changes and, more importantly, context switches from one topic to another. If you've been to DevWeek this year, I'm sure you enjoyed it: it's getting better year over year, and this is my third one so far.
Below you can find the materials for my eight sessions. If you've been to my workshop and haven't got the materials, please contact...
It's been a few weeks since my last post. Should I apologize? I really should. But with eight sessions and a workshop at DevWeek, I hope to make up for it in the upcoming weeks. Anyway, next week I'm giving a workshop at DevWeek, titled Making The Most Of C++ 11/14. It's a distilled summary of modern C++ that every C++ developer has to be aware of. This is a slightly longer description that what was published on the conference website.
The C++ language many of us are using today goes back more than thirty years. You might be using some “newer” features, such...
This is the last post in the series. We have a fully functional tuple class, with a decent implementation of tuple_cat -- but some reservations about its performance. In this post we're going to improve it considerably, at the expense of making the implementation more difficult. The main problem with what we did in the previous post is that we are creating many temporary tuple objects. When concatenating n tuples, we create n-2 intermediate tuples that hold partial results. But can it be avoided?
UPDATE (Feb 24): I forgot to credit Stephan T. Lavavej (a.k.a. STL, also the maintainer of Microsoft's STL)...
We are almost done. We have a pretty functional tuple that supports almost every operation mandated by the Standard. With one major exception: tuple_cat. First, let's see what it does:
auto t1 = tuple_cat(make_tuple(1), make_tuple(2)); // tuple<int, int>(1, 2)
auto t2 = tuple_cat(t1, make_tuple(3), make_tuple(4));
auto t3 = tuple_cat(t1, t1, t2, t2);
// t3 is a tuple of 12 ints: 1, 2, 1, 2, 1, 2, 3, 4, 1, 2, 3, 4
Hmpf. Obviously, tuple_cat is a variadic function template. tuple is itself a variadic class template, and we're now trying to build a variadic function template that takes any number of variadic class...
After doing all the heavy lifting in the previous four installments (, , , ), this one is going to be very lightweight. We will implement a few simple tuple non-member functions and helpers.
First, let's implement a very simple helper: tuple_size. It is a metafunction that returns the number of elements in the tuple.
Exercise 11: Implement tuple_size.
struct tuple_size; // undefined base template
template <typename... Types>
struct tuple_size<tuple<Types...>> : std::integral_constant<size_t, sizeof...(Types)>
Well, that was easy. Let's do another: forward_as_tuple. The basic idea is that you provide a set of elements and get back a tuple that has lvalue or rvalue references depending...
C++ 11 is truly beautiful. And one of the ways in which it is beautiful is how you can implement a compile-time and runtime-safe version of the popular C runtime function printf.
Originally, printf was implemented as a variadic function that parses its first argument (a format string) to determine how many additional arguments it should read from the stack. printf has no way of knowing how many parameters were actually provided; any mismatch means a nasty exception at runtime, or, worse, undesired output. For example:
printf("%d %d", 42);
The first version will probably work and print some arbitrary stack value...