constexpr Dynamic Memory Allocation, C++20

by Bartlomiej Filipek

constexpr has become a major feature for compile-time programming in C++. Introduced in a simple form in C++11 evolved into almost another “sub-language”, an alternative to regular template code. In C++20 you can even use std::vector and std::string in constexpr context!

In this article, I’d like to discuss constexpr memory allocations, a building block for std::vector. Let’s see how this feature works and see its limitations...

Creating other types of synchronization objects that can be used with co_await, part 9

by Raymond Chen

Last time, we tried to make an awaitable shared mutex, but ran into some problems...

Creating other types of synchronization objects that can be used with co_await, part 8

by Raymond Chen

Our next stop in showing off our library for building awaitable synchronization objects is the shared mutex. This one takes advantage of the “extra data” we had been hiding in our nodes...

C++20

by Rainer Grimm

My book C++20 is both: a tutorial and a reference for the C++20 standard. It teaches you C++20 and provides you with the details of this new thrilling C++ standard. The thrilling factor is mainly due to the big four of C++20...

What C++ Fold Expressions Can Bring to Your Code

by Jonathan Boccara

In the previous post we saw how fold expressions work. We saw how to define them, how to control their associativity, and how to handle empty variadic packs in a fold expression...

Don't automatically use auto parameters in C++

by Lesley Lai

Since C++14, we can create lambda expressions that take auto parameters. C++20 generalizes this idea by allowing us to do the same thing for regular functions. With this feature's advent, the programming style where all parameters are auto becomes popular among some C++ programmers. However, I think we should not use it if we had to. The more specific the type of the parameter is, the better.

Creating other types of synchronization objects that can be used with co_await, part 7

by Raymond Chen

Our next stop in showing off our library for building awaitable synchronization objects are the mutex and recursive mutex...

How C++ Resolves a Function Call

by Jeff Preshing

C is a simple language. You’re only allowed to have one function with each name. C++, on the other hand, gives you much more flexibility:

• You can have multiple functions with the same name (overloading).
• You can overload built-in operators like + and ==.
• You can write function templates.
• Namespaces help you avoid naming conflicts.

I like these C++ features. With these features, you can make str1 + str2 return the concatenation of two strings. You can have a pair of 2D points, and another pair of 3D points, and overload dot(a, b) to work with either type. You can have a bunch of array-like classes and write a single sort function template that works with all of them.

But when you take advantage of these features, it’s easy to push things too far. At some point, the compiler might unexpectedly reject your code with errors like:

error C2666: 'String::operator ==': 2 overloads have similar conversions
note: could be 'bool String::operator ==(const String &) const'
note: or       'built-in C++ operator==(const char *, const char *)'
note: while trying to match the argument list '(const String, const char *)'

Like many C++ programmers, I’ve struggled with such errors throughout my career. Each time it happened, I would usually scratch my head, search online for a better understanding, then change the code until it compiled. But more recently, while developing a new runtime library for Plywood, I was thwarted by such errors over and over again. It became clear that despite all my previous experience with C++, something was missing from my understanding and I didn’t know what it was.

Fortunately, it’s now 2021 and information about C++ is more comprehensive than ever. Thanks especially to cppreference.com, I now know what was missing from my understanding: a clear picture of the hidden algorithm that runs for every function call at compile time.

Creating other types of synchronization objects that can be used with co_await, part 6

by Raymond Chen

Our next stop in showing off our library for building awaitable synchronization objects is the semaphore. This will look very familiar because a semaphore with a maximum token count of 1 is the same thing as an auto-reset event, so we can just extend our auto-reset event implementation to support multiple tokens...

Creating other types of synchronization objects that can be used with co_await, part 5

by Raymond Chen

Our next stop in showing off our library for building awaitable synchronization objects is the auto-reset event...