The newest and latest (late-2020) Apple Macbook Air and Macbook Pro 13” with Apple Silicon has been out on the market for a while now. Recently, I had the priviledge of getting a Macbook Air with M1 chip as as a dev machine to test various things (c++, python, jupyter notebook) that I use.

From the Youtube reviews (MKBHD) and various benchmarking websites (Toms’ Hardware, Daring Fireball), I already know that the performance of the M1 chips is really impressive at the given power consumption; and that people are getting ridiculous battery lifes on their M1 Macs. However, as someone that intends to use the Mac as a development daily driver, my main concern is how my workflow and toolchain will work with the new Apple Silicon and ARM64 instruction set. After a few weeks of tinkering and exploration, I think it is safe to say that Apple has done an incredible job to ensure smooth transition to the new hardware, and that AMD/Intel/Microsoft or any other hardware manufacturer should be shitting their pants right now for the on-slaught that’s about to come.

While working in any large C++ project, we often deal with having to write small utility functions that takes in some temporary and then perform some operation on it to return a transformed variable. For example

std::string append_path(const std::string& basepath, const std::string& child_path)
{
    return basepath + "/" + child_path;
}

// Invoking this function:
const std::string basepath = "/var/tmp";
const std::string text_file = "some_file.txt";
const std::string new_path = append_path(basepath, text_file); // this works
const std::string other_new_path = append_path(basepath, "some_other_file.txt"); // this also works

Does this seems strange to you? We are requiring the variable to be passed in by reference. The "some_other_file.txt" argument in the 2nd invocation of the argument is a “r-value”, and we are able to refer to the content of this r-value string as a reference to some variable.

It turned out, as Herb Sutter explained it here:

The C++ language says that a local const reference prolongs the lifetime of temporary values until the end of the containing scope, but saving you the cost of a copy-construction (i.e. if you were to use an local variable instead).

So, effectively, the r-value life-time is extended to the function scope when it is being invoked as an argument to a function immediately after its definition.

Now I can rest easy, knowing that the behavior of my program won’t depend on how aggressive the compilers optimize or reuse the memory of variables that are no longer considered “needed” by scoping rules.

Programming or any problem solving skill is really all about distilling complex problems into simpler abstractions. The art of creating elegant abstractions is a skill that developers must acquire on their journey to master software craftsmanship. Terse abstractions that fully describes a problem helps reduce cognitive burden, allowing the developer to focus on what really matters in the code.

CMake while being arcane and quirky in its own way, is currently the standard cross-platform compilation platform for C++/C build systems. I think the power of CMake comes from all the community contributions and the knowledge base built up over the years.

I recently worked on a project to migrate it from an archaic Perl build system into the land of CMake. Following modern CMake practices really made dependency management a breeze (i.e. target based compilation flag specification, target based linking, transient header propagation via INTERFACE/PUBLIC/PRIVATE, generator expressions to optionally specify different compiler warning / optimization levels)

One of the things that took a little while for me to figure out is how to embed a GUI based application an application icon that is in a cross-platform friendly method. I googled around and really didn’t come across a simple enough solution, so I decided to roll my own.

As C++ coder, sooner or later you will encounter elements of meta-programming. It might be as simple a STL container. Or it might be a full blown template class that takes variadic arguments. I, myself, have also taken this journey. As I ventured deeper into meta-programming, acronyms such as CRTP, SFINAE really piqued my interest. Today, let’s talk about SFINAE.

SFINAE stands for “substitution failure is not an error”, and there has been numerous articles, stack overflow questions and blog posts on this topic:

In this part 2 of the Go channel series, I will expand the Channel<T> class we developed to support multiple elements, range for loops and asynchronous operations.

Part one of this series, where we built a simple Go channel with similar synchronization behavior is available here.

Buffered channels are desirable in many parallel applications such as work queues, worker/thread pools, MCMP (multiple consumers/producers) patterns.

Go channels is the de-facto synchronization mechanism in Go. They are the pipes that connect concurrent go routines. You can send values into channels from one goroutine and receive those values into another goroutine. Having channels have made writing multi-threaded concurrent programs really simple in Go. In this series, I wanted to see if it’s possible to re-create it in cpp.

Heap memory allocation via new and delete (or malloc or free for C) are unavoidable for more complex, large scale programs. However, it is a common misconception that free/delete will actually free the memory back to the operating system for other processes to use.

This is because there are actually two different types of memory allocation happening behind a malloc/new call. The first type, reserved usually for smaller allocations (less than 100 kb) uses sbrk(), which is a traditional way of allocating memory in UNIX – it just expands the data area by a given amount. The second type uses mmap() to allocate memory for larger chunks of memory. mmap() allows you to allocate independent regions of memory without being restricted to a single contiguous chunk of virtual address space. A memory mapped region obtained through mmap() upon unmapping will immediately release the memory back to the OS, whereas sbrk() will keep the released memory within the process for future allocations.

C++ templates are useful constructs to reduce code bloat (I think of them as fancy copy and paste) without any performance overhead at run-time. However, to use them effectively might require some practice. One issue I recently ran into while working with templates is the following:

Suppose I have a generic class Foo<T> that takes a template argument, I need to place Foo<T> in a container to be iterated upon or to be looked up later. However, I might have multiple instantiations of Foo<T> of different types (i.e. int, float, double, bool), this makes it hard to use STL containers since these containers require the elements to be of a single type.

This is the obligatory “Hello World” post.

After various attempts to use Wordpress, Vue, React, I’ve decided to just switch to Github pages (Jekyll). The setup was fairly painless:

• The official Github pages guide was very helpful
• To re-direct my custom domain (bolu.dev) to the Github pages, I followed Hossain Khan’s guide here: https://medium.com/@hossainkhan/using-custom-domain-for-github-pages-86b303d3918a

The main advantage of moving to Github pages is the ease of setup and migration should I need to do so in the future. There’s no database, almost no-setup, and I can make use of standard git workflows. The posts are in markdown so I can work on it piece-meal whenever I want. Looking forward to see if this motivates me to write more.