Automatic Object Linkage, with Include Graphs -- Thomas Young

For C++ code-bases with multiple targets and shared code elements, static libraries are kind of the default approach, but is there a better way to set this up?

Automatic Object Linkage, with Include Graphs

by Thomas Young

From the article:

In this post I describe an alternative approach to sharing source code elements between multiple build targets.

 

...

We'll need to enforce some constraints on the way the source code is set up, notably with regards to header file organisation, but can then automatically determine what to include in the link operation for each build target, based on a graph of include relationships extracted from the source files.

The resulting dynamic, fine grained, object-file centric approach to code sharing avoids the need for problematic static library decomposition, and the associated 'false dependencies'.

Transforming std::find into std::ranges::find -- Christopher Di Bella

Today, we dive into what std::find does, and how we can leverage various concepts to cleanly express its requirements, as achieved in std::ranges::find.

Transforming std::find into std::ranges::find

By Christopher Di Bella

From the article:

... The code is nearly the same, but not quite. Where it differs is in how we determine the end of the sequence, how we take the successor of our current element, and how we retrieve the value. While this is conceptually the same, it’s implementationally different.

...

Iterators are a topic rich with mathematics. Because they are part of what makes generic programming so powerful, this topic spans multiple chapters in books on generic programming.

...

we’ll now refine find to consider the EqualityComparableWith concept that we laboured over in the last article....

CppCast Episode 152: C++ London Uni with Tom Breza, Oliver Ddin and Tristan Brindle

Episode 152 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Tom Breza, Oliver Ddin and Tristan Brindle to discuss the C++ London Uni group and their approach to teaching C++ to the community.

CppCast Episode 152: C++ London Uni with Tom Breza, Oliver Ddin and Tristan Brindle

by Rob Irving and Jason Turner

About the interviewees:

Tom arrived in London at age 22 with £200 to his name, not knowing a single person. After 6 months Tom managed to start business - PC Service, that provides IT support to SMBs and runs it since then. Tom's team help many customers from small businesses to top celebrities and Royal Families. Now with over 20 years of experience, Tom set his mind on new challenges and decided to learn software development, specifically C++ and helps others to learn through C++ London Uni.

Oliver has been a C++ hater since 2008 - fortunately, that all changed with C++11 and he's firmly an enthusiast now. He's spent his time doing everything from embedded devices to network engineering and now Internet security related endeavours. He's a big proponent of writing software in a style driven by some form of testing and its place in pushing you towards well-architected, maintainable code. In his spare time he also co-organises C++ London Uni which provides free lessons for people wanting to get into developing C++ and the wider ecosystem around it.

Tristan is an independent contractor and C++ enthusiast based in London. He’s particularly interested in standardisation and making C++ an easier language to use and teach. He can be found on Twitter @tristanbrindle and occasionally blogs about C++ at tristanbrindle.com.

Hello CMake!--Arne Mertz

Do you use it?

Hello CMake!

by Arne Mertz

From the article:

Since I have mentioned CMake in a handful of past blog posts, it is time to give a short introduction for those that don’t know it yet.

CMake is one of the most popular build systems for C++ out there. One of the main reasons probably is that it is cross-platform: It does not build the project itself but operates a platform-specific system. That means it can generate Makefiles, ninja-build files, or project files for Visual Studio or Xcode, to name just a few...

Quick Q: use of constexpr in header file

Quick A: const in a header implicitely means static.

Recently on SO:

use of constexpr in header file

constexpr implies const and const on global/namespace scope implies static (internal linkage), which means that every translation unit including this header gets its own copy of PI. The memory for that static is only going to be allocated if an address or reference to it is taken, and the address is going to be different in each translation unit.

That implied static for const variables was introduced specifically to use const instead of #define in header files in C++ to define constants. Without static there would be multiple symbol definitions linker error if that header file is included in more than one translation unit which were linked together.

In C++17 you can also make it inline, so that there is only ever a single copy of PI if an address or reference to it is taken (i.e. not static). inline variables were introduced in C++17 to allow for header-only libraries with non-const variable definitions in the header files.

In other words, you should use constexpr for your constants in header files, if possible, otherwise const. And if you require the address of that constant to be the same everywhere mark it as inline.

CppCast Episode 151: sol2 and std::embed with JeanHeyd Meneide

Episode 151 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by JeanHeyd Meneide to discuss the sol2 library and his proposal for std::embed.

CppCast Episode 151: sol2 and std::embed with JeanHeyd Meneide

by Rob Irving and Jason Turner

About the interviewee:

ThePhD -- known in meatspace as JeanHeyd -- is a Computer Science undergraduate at the Fu Foundation School of Engineering in Columbia University. They are currently working on Open Source C++ and C++ Standardization projects, as well as exploring graphics programming. They are currently dabbling with Haskell and Elm for fun, and are attempting to wrangle their biggest open source project -- sol2 -- into a newer, better version of itself. The nickname is a std::promise<> on their std::future<>.

 

Error Handling and std::optional--Bartlomiej Filipek

Do you have a prefered way?

Error Handling and std::optional

by Bartlomiej Filipek

From the article:

In my last two posts in the C++17 STL series, I covered how to use std::optional. This wrapper type (also called “vocabulary type”) is handy when you’d like to express that something is ‘nullable’ and might be ‘empty’. For example, you can return std::nullopt to indicate that the code generated an error… but it this the best choice?

Declarative Functional APIs – A.K.A. Abusing Lambda Parameters--Philippe Groarke

Take some time to clear your thoughts before reading!

Declarative Functional APIs – A.K.A. Abusing Lambda Parameters

by Philippe Groarke

From the article:

Functional APIs are a joy to work with. Not only do they help eliminate certain bug categories, but they tend to be very flexible and reusable. Today I present a technique that has emerged while I was simplifying some lambda based APIs. C++17 makes template meta-programming much more palatable, I dare not imagine what this would look like in C++11...

Should Span Be Regular?--Barry Revzin

Do you have an opinion?

Should Span Be Regular?

by Barry Revzin

From the article:

In my last post, I talked about the concept of Westie types (yes, I am trying to make this happen), what Regular means, and which of them are Regular. I went through an explanation for why means for span is not Regular and potentially why it should be. After lots of resulting conversations with several people (thanks Zach Laine, Nicole Mazzuca, Eric Niebler, John Shaw, Tim Song), I thought it was necessary to write a follow up with more details and more argument...