As told by Matt

Go Tip: Creating Closed Interfaces

Sat, 14 Dec 2024 00:00:00 +0000

In go , interfaces are satisfied by any type that implements all of the methods defined in the interface. This makes Go interfaces “open” types, meaning that any type can satisfy an interface at any time.

However, did you know that Go actually has a mechanism for restricting who can implement these types? This go-tip will tell you how you can accomplish this.

Blog Reboot

Tue, 02 Jan 2024 23:47:29 +0000

It’s been a long time since I’ve last updated this blog – and I think I’m finally ready to reboot it.

A lot has changed since my last article nearly 3 years ago:

I changed jobs a number of times, and am now begrudgingly working as a Go developer professionally.
I found new love of the Rust programming language and started writing rust projects in my spare time.
I’ve learned a lot about working in domains ranging from GCP to working embedded on Texas Instruments SoCs .
I haven’t written any practical C++ in nearly a year.

I have a lot to talk about, and hope to use this blog as somewhere I can share my knowledge and experiences with others that hope to learn and grow from them.

Reflecting Over Members of an Aggregate

Sun, 21 Mar 2021 11:31:40 -0400

A little while back a friend of mine and I were talking about serialization of struct objects as raw bytes. He was working with generated objects that contain padding, but the objects needed to be serialized without the padding; for example:

struct Foo
{
 char data0;
 // 3 bytes padding here
 int data1;
};

In the case he described, there are dozens of object types that need to be serialized, and all are:

Generated by his organization (so they can’t be modified), and
Are guaranteed to be aggregates

Being a template meta-programmer, I thought it would be a fun challenge to try to solve this in a generic way using c++17 – and in the process I accidentally discovered a generic solution for iterating all members of any aggregate type.

Getting an Unmangled Type Name at Compile Time

Tue, 09 Mar 2021 19:21:59 -0500

Getting the name of a type in C++ is a hassle. For something that should be trivially known by the compiler at compile-time, the closest thing we have to getting the type in a cross-platform way is to use std::type_info::name which is neither at compile-time, nor is it guaranteed to be human-readable.

In fact, both GCC and Clang actually return the compiler’s mangled name rather than the human-readable name we are used to. Let’s try to make something better using the modern utilities from c++17 and a little creative problem solving!

Builder Pattern: Expressing ownership transfer

Tue, 02 Mar 2021 17:06:40 -0500

The Builder pattern is a common design in software development for late-binding inputs to allow for iterative construction. This pattern, when applied in c++, leaves one very obvious question: Can we present this to consumers in an optimal way?

More specifically: when we call build(), should we be moving any temporary internal state, or copy it? Can we express both in a safe and idiomatic way to consumers?

Final Poetry

Sun, 28 Feb 2021 01:23:18 -0500

Note The C++WTF segment shines a light on the dark and esoteric corners of the C++ language for fun and profit The C++ standards committee is very strongly against producing any kind of breaking changes when considering new language features – especially keywords. Over the course of standardization, this has lead to terms like auto being repurposed, or awkward keywords like co_await and co_yield being introduced in C++20 to avoid breaking a handful of projects in the world that might possibly be using await or yield in their vocabulary.

Creating a Fast and Efficient Delegate Type (Part 3)

Fri, 26 Feb 2021 22:19:51 -0500

In the previous post we updated our Delegate object that we’ve been working on since the first post to support covariance.

In this post, we will look at how to make this a true zero-overhead utility

Creating a Fast and Efficient Delegate Type (Part 2)

Fri, 26 Feb 2021 22:18:32 -0500

In the previous post , we saw how we could build a simple and light-weight Delegate type that binds free functions, and member functions. However we have a notable limitation that we require specifying the type of the members being bound (e.g. d.bind<Foo,&Foo::do_something>()). Additionally, we’re forced to bind only the exact type. We can’t bind anything that is covariant to it.

Lets improve upon that.

Creating a Fast and Efficient Delegate Type (Part 1)

Wed, 24 Feb 2021 20:03:14 -0500

When working in C++ systems, a frequent design pattern that presents itself is the need to bind and reuse functions in a type-erased way. Whether it’s returning a callback from a function, or enabling support for binding listeners to an event (such as through a signal or observer pattern), this is a pattern that can be found everywhere.