C++ Programming

Implementing Concepts in C++14

I haven't posted in quite some time. I'll explain why in a later, more somber, post. For now, I want to show some cool stuff.

CppCon 2016 just ended. I had a wonderful time at the conference this year. There were some very interesting talks and panels (which I recommend you watch on YouTube, once they are uploaded). The ones that stood out to me were the coroutines talks. I also got to participate in SG14 and I started writing my first proposal for an intrusive smart pointer, which will hopefully be sent in before the Issaquah mailing deadline. There was quite a bit of interest from SG14, as well as Gor Nishanov from Microsoft. On Wednesday night, I decided to ask if there was a slot left for a thursday lightning talk and I was able to get myself squeezed in. The talk was originally titled No Concepts Beyond This Point, but I later wanted to call it Sic Semper SFINAE. Effectively, I showed a brief example on how to implement concepts (at least, the compile time interface constraints) in C++14. I ran out of time, however, so I decided to write this post to explain it a bit better and to show it off. It's not perfect; Extra work is required for placeholder types (assuming it is even possible). However, in today's post I'll be showing you how to implement them yourself. I'll be using the code I wrote before my lightning talk as a base. I only had 5 minutes to explain everything in my talk, so I'll be able to go into more depth and explain show it working.

Read more »

An Attempt to Explain Monads in C++

Last time, I spoke about some potential continuations that someone can do in C++ with optional types. I briefly stated, in regards to the Boost.Expected proposal:

This is all well and good, however I noticed that these choice of words 'map' or 'bind' aren't what I think when reading.

Someone pointed out to me that the 'map' call comes from one of the three operations one can perform on a monad. The other two being 'join', and 'return'. After digging into the Boost.Expected proposal some more, I finally had that epiphany where one understands what a monad is. As such, I want to keep with the time honored tradition of trying to explain it to others, and continuing to confound the congregation of programmers who haven't yet grokked it. However, I'll explain it in the context of C++, rather than trying to explain Haskell, and how some of its features map to C++. And while burritos are delicious, I won't be referencing them at all.

Read more »

Optional Types and Lightweight Continuation Passing in C++

MNMLSTC Core is starting to near its 1.2 release target, and this will most likely be the last version that targets C++11 and may be the last non-bugfix release for the 1.x series. There are many reasons for this, but the primary one is the difficulty that exists in implementing C++17 proposals without C++14 language features. Before I move on to begin work on 2.0, I'm going to add be adding several extensions to the proposals that Core alrady implements. Specifically, I'll be adding extensions to the optional types. As of right now, the match member function that is provided for core::variant<Ts...> is now available for all the optional types that Core provides (optional<T>, expected<T>, and result<T>). However, this post is about a different feature that I'll be adding and it may be one that doesn't exist beyond the 1.x series. Please note that this post makes extensive use of C++14 library features that are implemented in MNMLSTC Core, as well as the extensions MNMLSTC Core provides (namely result<T>). In addition, the code contained within is not 100% correct, and should be approached as though it were pseudo code.

Read more »

C++ Needs Better I/O Facilities

C++ is not well liked by a large number of non-C++ programmers. One of the arguments that has stood the test of time against C++ is the streams library. It's even a point of contention within the C++ community. The main arguments against the entire streams library are usually:

  • Overloading operator <<
  • Performance
  • 'God Objects'

We're going to ignore that first bullet point, however, because it is entirely opinionated. Developers can argue about overloading operators and what should and should not be overloaded all day (and they usually do).

Read more »

RValue Reference Implications In C++11

There are several implications that one has to realize when it comes to using rvalue references in C++11 APIs. For starters, requiring an rvalue reference as a parameter to a function implies the following:

  • The object being passed in may be mutated
  • The object being passed in may exist until program exit
  • You (the caller) no longer own the object being passed in

This is fairly large in terms of writing an API. In days of yore, before the existence of rvalues and move semantics, one might have used a pointer, or non-const reference to designate that an object would be mutated. They may have gone a step further and passed the object in by value to show that a deep copy would be made as the object passed in was no longer your concern. But none of these implied one very important feature that C++ technically lacks.

Read more »