Tuesday, October 27, 2015
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...
Thursday, October 22, 2015
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...
Thursday, July 30, 2015
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,...
Monday, December 1, 2014
The Current Landscape of Native Memory Diagnostics
Leak diagnostics is a nasty business in native applications. There have been many attempts at solving this problem automatically. To name a few:
The CRT Debug Heap (which is no longer used by default in Visual Studio 2015! - See update below.) can help identify memory leaks by associating each allocation with additional data on the allocating source file and line number. At program exit (or whenever a special CRT function is called), all blocks that haven't been freed are printed out. This has been around forever. The problem is that you need to...