Skip to content →

Author: bitweeder

Why Not Abseil? Part 0

When I first started the update process for the Lucena Utility Library (LUL), there were no good equivalents that I was aware of in the open source world. A short time after I started blogging about it, Google began raising the profile of Abseil, its C++ augmentation library. Pieces of Abseil deal with feature detection and compiler abstraction, pieces of it provide abstractions and back-ports of Standard Library features, and pieces are centered around utility code and replacements for various pieces of Standard Library functionality. So how does it compare to LUL? In this part, we’ll start by breaking down…

Comments closed

Tripping Over the One Definition Rule

Stepping away from my series on updating the Lucena Utility Library (LUL) for a bit, I’d like to discuss a passing reference I made to the difficulty in providing header-only reference implementations for some of the newer Standard Library pieces that haven’t passed into ubiquity on our various target platforms. Specifically, I implied that avoiding One Definition Rule (ODR) violations made this impossible. I’m going to qualify that statement and describe some of the issues in detail. The One Definition Rule: a refresher In my experience, the ODR is one of the most perniciously botched requirements in all of C++.…

Comments closed

Updating the Lucena Utilities Library for C++17, Part 2—Feature Detection

This is the continuation of a series on the Lucena Utilities Library (LUL). The backbone of any sort of compile-time abstraction is a set of feature-detection flags. More generally, it’s a set of feature-detection tests, but ideally, you want to run the tests once, store the results, and then just refer to those forever after. These sorts of tests are necessary because different compilers and Standard Library implementations support different subsets of the developing C++ Standard; furthermore, they all have differing methods of communicating this information to the user. Note that determining feature availability is separate from detecting feature correctness—even…

Comments closed

Updating the Lucena Utilities Library for C++17, Part 1—Determining Supported Configurations

This is the continuation of a series on the Lucena Utilities Library (LUL). Today, I’ll outline some requirements for the Library, and then discuss supported configurations. C++17, Build Systems, and More As a tool intended to be picked up by new projects and used over the course of years, it is sensible to focus on C++17 as a baseline. Supported platforms are assumed to have fully-compliant C++14 implementations and build with C++17 as the target dialect. LUL will focus on smoothing out the behavior of non-conforming compilers and incomplete implementations, providing aliases to equivalent compiler extensions, reference Standard Library and…

Comments closed

Updating the Lucena Utilities Library for C++17, Part 0—Evaluation

This is the beginning of a series on the Lucena Utilities Library. The purpose of the Lucena Utilities Library (LUL) is to abstract the build environment. It’s a foundational tool that should allow code built on top of it to remain agnostic regarding the underlying compiler, Standard Library, build system, and aspects of the runtime. Note that LUL is specifically not a build system, but it does try to shield a project from details of the build system at the code level. When the functionality was first isolated into a standalone library, a few other pieces came along for the…

Comments closed