Odin Holmes

speaker

Odin was allocated from a pool of hippies in the middle of the forest. He spent most of his career designing electronic circuits and programming micro controllers in assembler. One day after having shot himself in the foot particularly badly a friend introduced him to C++, a seriously powerful and ongoing addiction followed. Odin has authored many proof of concept libraries in the embedded field and is trying to revolutionize this domain. Odin co-authored the kvasir::mpl library, co-founded the embo.io conference and was a heavy contributor to the brigand library. In his day job, he teaches people how to shoot themselves in the foot less and get more from their compiler, both with his in-house team as well as in a training and consulting role.

 

Presentations

boost.tmp: Your DSL for Metaprogramming - Part 1 of 2 (2018)


At last years code::dive I presented new ways to write algorithms in template metaprogramming with the kvasir::mpl library. In this talk, after a brief review of last years material, I would like to show how my latest creation: the boost.tmp library (not yet submitted to boost) offers a relatively feature complete DSL with which one can meet the vast majority of metaprogramming needs with no disambiguators and odd keywords. We can even benefit from the added clarity of a DSL without increasing compilation time.

We will also explore other strategies of SFINAE use, more efficient use of type_traits as well as a teaser of my vision of what fusion style metaprogramming should look like.

 

boost.tmp: Your DSL for Metaprogramming - Part 2 of 2 (2018)


At last years code::dive I presented new ways to write algorithms in template metaprogramming with the kvasir::mpl library. In this talk, after a brief review of last years material, I would like to show how my latest creation: the boost.tmp library (not yet submitted to boost) offers a relatively feature complete DSL with which one can meet the vast majority of metaprogramming needs with no disambiguators and odd keywords. We can even benefit from the added clarity of a DSL without increasing compilation time.

We will also explore other strategies of SFINAE use, more efficient use of type_traits as well as a teaser of my vision of what fusion style metaprogramming should look like.

 

What I Wish They Told Me - Part 1 of 2 (2018)


Coming into software from an electronic engineering background I found that an overarching grand theory is missing in this domain. In EE we have the Maxwell equations as well as a few other fundamentals which everything builds on. Although to this day I do not claim to fully understand these equations, and my impression is that essentially no one understands their implications fully, they serve as a structure with which one can organize all the knowledge which one gains along the way.

In software, I felt more like I was presented with a giant grab bag of piecemeal knowledge and experience, much of which contradicts each other and most of which is outdated in some way. This often led me to question what "good" code is and if my code was "good" while lacking the tools to reason about it in a first principal manor. How should a beginner critique a piece of code which functions as expected? Surely there is still room for improvement.

Although I am no Maxwell or Faraday and cannot produce an overarching theory myself I would like to share with you the observation which I have made over my career which helps me categorize and reason about the quality and applicability of the giant grab bag of information which we call software engineering practices. From reasoning about the performance of code to patterns which increase the probability of correctness as well as questions like "what is architecture really?". I will do my best to efficiently dump my brain onto slides and hope to provide structure in the minds of beginner and intermediate programmers.

 

What I Wish They Told Me - Part 2 of 2 (2018)


Coming into software from an electronic engineering background I found that an overarching grand theory is missing in this domain. In EE we have the Maxwell equations as well as a few other fundamentals which everything builds on. Although to this day I do not claim to fully understand these equations, and my impression is that essentially no one understands their implications fully, they serve as a structure with which one can organize all the knowledge which one gains along the way.

In software, I felt more like I was presented with a giant grab bag of piecemeal knowledge and experience, much of which contradicts each other and most of which is outdated in some way. This often led me to question what "good" code is and if my code was "good" while lacking the tools to reason about it in a first principal manor. How should a beginner critique a piece of code which functions as expected? Surely there is still room for improvement.

Although I am no Maxwell or Faraday and cannot produce an overarching theory myself I would like to share with you the observation which I have made over my career which helps me categorize and reason about the quality and applicability of the giant grab bag of information which we call software engineering practices. From reasoning about the performance of code to patterns which increase the probability of correctness as well as questions like "what is architecture really?". I will do my best to efficiently dump my brain onto slides and hope to provide structure in the minds of beginner and intermediate programmers.

 

The fastest template metaprogramming in the West (2017)


Although a talk on a C++11 metaprogramming may seem outdated in 2017 we have only recently found new ways to leverage aliases to do much of the heavy lifting. More alias use as well as some key implementation details allow us to beat other libraries, more modern language features and even some compiler intrinsics in compilation speed. This talk will outline the advantages of the continuation style metaprogramming which we developed in the kvasir::mpl library. It will also discuss some concrete use cases including ways to interface with Boost.Hana when a run time component is not needed.

 

Modern Embedded APIs, Bare Metal Should Cause Less Pain (2016)


Scott Meyers has often publicly expressed our communal goal as software developers and library designers: “make interfaces easy to use correctly and hard to use incorrectly”. Current bare metal embedded code is often about as far from that goal as syntactically possible. In other words we have failed at that goal, as is true in many other domains. There are many reasons given for this disparity, however most of them are either myths or outdated. C++11/14 has given us an incredible new tool set to work with, its high time we used it. The domain specific constraints, namely the flexibility of threading model, memory management, exotic hardware drivers and the uncompromising need for speed are quite stringent. On the other hand the fact that programs are smaller and RTTI is usually stripped any way make this domain a metaprogrammers paradise. In this talk I will show many domain specific as well an universal methods with which complex, powerful and highly flexible libraries leveraging advanced generic techniques such as lazy evaluation and policy based class design can be hidden behind friendly, intuitive and fully static checked public interfaces. This will not be a typical API talk, lets face it, most "typical" APIs are outdated. This will be a rabble rousing "rethink what you think you know about APIs" talk and a "heres a syntactic tool you (probably) didn't know existed" talk.