Articles & Books

Creating other types of synchronization objects that can be used with co_await, part 10--Raymond Che

The series continue.

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

by Raymond Chen

From the article:

We’ve been looking at creating different types of awaitable synchronization objects. This time, we’re going to create something that doesn’t exist in the normal Win32 repertoire: An event where you can wait for the event to be in a desired state, either set or reset. Normal Win32 events allow you to wait for them to be set, but you cannot wait for Win32 event to be reset. The usual workaround is to have two events...

constexpr Dynamic Memory Allocation, C++20--Bartlomiej Filipek

Constexpr all the things.

constexpr Dynamic Memory Allocation, C++20

by Bartlomiej Filipek

From the article:

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...

C++20 by Rainer Grimm [Leanpub PDF/iPad/Kindle]

Will you read it?

C++20

by Rainer Grimm

From the article:

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...

Don't automatically use auto parameters in C++ -- Lesley Lai

Should we use almost always auto parameters?

Don't automatically use auto parameters in C++

by Lesley Lai

From the article:

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.

How C++ Resolves a Function Call--Jeff Preshing

Know everything about it.

How C++ Resolves a Function Call

by Jeff Preshing

from the article:

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.