Month: February 2018

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…

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…

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…