DEV Community: Coral Kashri

C++20 - s(uper)size

Coral Kashri — Wed, 08 Jan 2025 18:34:08 +0000

C++20 introduced us std::ssize which stands for signed size. After years of using size_t as a return type from container.size() function, the understanding that this usage is dangerous had it effect, and now the usage of std::ssize is considered for the best practice.

The reasoning for that is the following simple iteration example:

for (auto i = container.size() - 1; i >= 0; ++i) { /* do something... */ }

This is unfortunately is an infinite loop, as i type is unsigned long long so it'll always be greater than or equals to 0.

Now, let's use the same loop with std::ssize:

for (auto i = ssize(container) - 1; i >= 0; ++i) { /* do something... */ }

Even if the container is empty, i would be initialized to -1 and the behavior would be as expected.

If you are still using C++ version lower than 20, you can use: static_cast<int64_t>(container.size()) or to create a wrapper function to do that for you:

template <typename T>
int64_t ssize(const T& container) {
    return static_cast<int64_t>(container.size());
}

Good luck!

Reading Text Files Like a Pro - C++

Coral Kashri — Tue, 07 Jan 2025 20:58:35 +0000

Are you tired of the old way of reading text files in C++? Have you always dreamed about reading them in Python-like fashion? Now you can. Enjoy.

for (std::string_view line : file_reader<'\n'>(file)) {
   std::cout << line << "\n";
}

Using std::istream_iterator and a delimiter hack, we can enjoy the new world of C++.

See the full header in my repo: https://github.com/coralkashri/simple_file_reader_cpp ad if you like it, you can always give it your star ✨

ADL – Avoid Debugging Later

Coral Kashri — Fri, 20 Dec 2024 12:47:39 +0000

Back in the day, being a witch was considered a grave crime. Today, we’re diving into one of C++’s lesser-known spells: ADL (Argument-Dependent Lookup). But before we explore this arcane magic, you must heed a warning—black magic comes with consequences. ADL is particularly treacherous, often leading to frustrating and hard-to-debug issues. Whenever possible, it’s wise to avoid casting this spell unless absolutely necessary.

Ingredients

Every spell needs ingredients, this time the only ingredients you need are a C++ compiler and a function that accepts at least one parameter, but there is a ~~try~~ catch, the parameter type has to belong to the same namespace of the function.

Casting the Spell

This spell works in shadows—you must look closely to uncover its effect.


std::cout << "Can you see me?";

Should the spell have passed you by, I’ll summon its power again for your eyes:


std::vector<int> a{1}, b{2};
swap(a, b);

If the spell’s effect remains elusive, let’s summon the entire code for you to see:


#include <vector>

int main() {
    std::vector<int> a{1}, b{2};
    swap(a, b);
    return 0;
}

And there it is, I didn’t use using namespace std; and yet I called std::swap function without the std:: prefix.

Dangerous Path

Before we dive into unveiling the syntax secrets, this is the place for warning signs. We all know that using namespace std; is considered bad practice—and for a good reason. When you import an entire namespace into your own without being fully aware of the functions and names you’re bringing in, collisions can occur. Such collisions might result in calling an unintended function or class, often one with a slightly different algorithm or mechanism (after all, there’s usually a reason for the identical naming).

Calling an unexpected function might unintentionally summon dependencies from distant, unforeseen corners of your code, and in doing so, awaken Undefined Behavior lurking quietly in the shadows, waiting for the right moment to strike.

This ‘spell’ exposes you to the exact same issue, even without explicitly using using namespace. There are situations where you may need to cast this spell to achieve generic or scalable code. However, even in those cases, you must ensure the area is clear. Treat these spell locations as dangerous and suspicious zones —mark them clearly, and suspect them first whenever a bug appears nearby.

Syntax Ritual: Unveiling the Dark Art of ADL

This spell was originally crafted to support the well-known foundation of C++ code:


std::cout << "Hello World";

This simple, foundational code uses ADL to access std::operator<<(std::ostream&, const char*), as the actual code is:


std::operator<<(std::cout, "Hello World"); // Without using ADL
operator<<(std::cout, "Hello World"); // Using ADL

The general idea behind this magic is that the compiler searches for a matching function in the current namespace and in the namespaces of each argument in the function call. For example, in the code above, the operator<< is located in the std namespace, and the argument std::cout also belongs to the same namespace.

However, there are many more rules regarding what the lookup would contain in each case. The exact rules of the ADL can be found on cppreference.

A slightly more complex example comes from my experience with the dlib library, which looks like this:


namespace dlib {
    class dense_feature_extractor {
    public:
        friend void serialize(const dense_feature_extractor& item, std::ostream& out) {
            out << "dense_feature_extractor::serialize\n";
        }

        friend void deserialize(dense_feature_extractor& item, std::istream& in) {
            std::cout << "dense_feature_extractor::deserialize\n";
        }
    };

    class matrix {};

    void serialize(const matrix& m, std::ostream& out) {
        out << "dlib::serialize(matrix)\n";
    }

    void deserialize(const matrix& m, std::istream& in) {
        std::cout << "dlib::deserialize(matrix)\n";
    }
}

Now, it becomes interesting: without ADL, we can’t access the serialize and deserialize friend functions inside the dense_feature_extractor class, unless we modify the library to declare them outside the class or make them static functions within the class.

By casting a few ADL spells, we can craft the following function:


dlib::matrix m;
dlib::dense_feature_extractor d;
serialize(m, std::cout); // dlib::serialize(matrix)
// same as: dlib::serialize(m, std::cout);
serialize(d, std::cout);// dense_feature_extractor::serialize
deserialize(m, std::cin); // dlib::deserialize(matrix)
// same as: dlib::deserialize(m, std::cin);
deserialize(d, std::cin); // dense_feature_extractor::deserialize

Since the calls appear identical, we can generalize them as follows:


template <typename T>
void dlib_serializer(const T &val) {
    serialize(val, std::cout);
}

template <typename T>
void dlib_deserializer(T &val) {
    deserialize(val, std::cin);
}

void func() {
    dlib::matrix m;
    dlib::dense_feature_extractor d;
    dlib_serializer(m);
    dlib_serializer(d);
    dlib_deserializer(m);
    dlib_deserializer(d);
}

The Spell You Might Unintentionally Already Cast

This spell is subtle and elusive, and you may already be summoning it without even noticing—simply by forgetting the std:: prefix (or any other namespace’s arcane sigil). The silver lining is that now, armed with this knowledge, you’ll be able to spot its presence in any code that calls upon it.

Special Thanks

Ellie Bogdanov for spelling assistance.
ChatGPT for the logo and for grammar and spelling assistance.

It’s just ‘,’ – The Comma Operator

Coral Kashri — Tue, 22 Oct 2024 02:28:03 +0000

We all know that every ‘,’ matters in this language, so I decided to talk directly about that character today. So, how much impact can be for such a small little character?

The Comma Operator

This operator comes from C, where it tells the compiler to evaluate all the expressions (left to right) and to return the result of the latest evaluated expression. For example:


int a, b;

a = 5, b = 4, b += a, ++a, std::cout << b << " " << a; // Prints 9 6

Another example of that operator usage is as follows:


for (size_t i = 0, k = 500; i < 10; ++i, ++k) { /*...*/ }

We can see this operator in action in the third section of the for statement. It evaluates the ++i and then evaluates ++k.

Not Every Comma is The Comma Operator

Although it might be confusing, not every comma we see in our code uses the comma operator. For example, when we pass parameters into functions, define the arguments we want to pass to the template or declare multiple objects using commas, these cases do not use the comma operator. Moreover, in the cases of passing arguments to functions, the evaluation order is not defined. Examples:


template <typename T, typename V> void func(int, int, int);
int a = 5, b = 6, c = 7; // Not the comma operator
for (int i = 1, j = 2; i < 5; ++i); // Not the comma operator
func<int, float>(a, b, c); // Not the comma operator

At this point, some of you might think there is no reason to be afraid of such an operator, if all it does is evaluate expressions left to right. Well, we are talking about C++ here, and I think it’s time to move to the spooky sides of this operator.

Fold Expressions

Another known usage of the comma operator is as part of fold expressions (Since C++17). To apply multiple unrelated expressions on the variadic parameters, we can use the comma operator as in the following example:


template <typename... ArgsF>
void call_functions(ArgsF&&... argsf) {
    (argsf(), ...);
}
/*...*/
call_functions(
  [] { std::cout << "Func1\n"; },
  [] { std::cout << "Func2\n"; },
  [] { std::cout << "Func3\n"; }
);

The ‘,’ is out there

About a year ago someone published on Reddit the following example:


for (int i = 0; i < 10,000; i += 1)

At first glance, there is nothing wrong with this code, and yet this loop will perform 0 iterations.

The comma operator is attached between the following expressions: i < 10 and 000. Therefore it performs the left expression and evaluates true and then performs the right expression, evaluates false, and returns the latter.

Let’s look for another example:


int x = 5, y = 6, z;
z = (x, y);

In this example, the two expressions are x and y. The compiler first evaluates x and then y and returns the latter. But what would happen if we remove the parentheses?


int x = 5, y = 6, z;
z = x, y;

Well, this time the expressions are z = x and y. The exact opposite of the previous example.

Dangerous Yesterday, Powerful Today

Before C++23, subscript expression (operator[]) could accept only a single argument. The following example is legal until C++20:


class Container {
public:
    int& operator[](int a) { /*...*/ }
};

...

Container c;
c[1, 4] = 5; // <--

This mistake might make someone believe it’s about accessing a specific cell in a matrix located in row 1 column 4, when it actually ignores the 1 and passes only the number 4 to the operator function.

Since C++20 using the comma operator without parentheses (()) inside subscript expressions is deprecated, and since C++23 it’s illegal as the operator might accept more than one parameter and the compiler will generate a matching error to a wrong number of parameters.

In C++23 we can see an example of the usage of this new language ability in the implementation of mdspan (which was part of the motivation for this ability).

Usage example with parentheses:


Container c;
c[(1, 4)] = 5; // The intention is clear: Only one parameter is passed to the operator.

Overloading Comma Operator

Now that we understand the basic risk of using the comma operator, it’s time to have some fun with it and stretch the limits of this pranking operator.


template <typename T>
std::ostream& operator,(std::ostream& out, T val)
{
    return out << val;
}

int main() {
    std::cout, "hello ", "world ", 42; // Prints "hello world 42"
    return 0;
}

Yes, it’s legal. But we can stretch the rules a little bit further:


template <typename T, typename P>
T operator,(T lhs, P rhs)
{
    return lhs;
}

int main() {
    int x = 5, y = 6, z;
    z = (x, y);
    std::cout << z; // Prints 6

    std::string str1 = "5", str2 = "6", str3;
    str3 = (str1, str2);
    std::cout << str3; // Prints 5
    return 0;
}

This time it’s a little bit more confusing: Why does the new overload have no effect on the first case, and does have an effect on the second one?

The reason is that the comma operator overload (and any other operator’s overloading) has to accept at least one parameter of class or enumeration type. Therefore the instantiation of int operator,(int, int) is not legal and doesn’t apply to the first case (which uses the regular rule of comma operator).

If you also insist on forcing the first example to work by the new rule, we can make a little change:


struct MyInt {
    MyInt(int a) : a(a) {}
    operator int() { return a; }
    int a;
};
/*...*/
MyInt x = 5, y = 6;
int z;
z = (x, y);
std::cout << z; // Prints 5

And a little bit of strings math:


using namespace std::string_literals;

int operator,(std::string_view s1, std::string_view s2)
{
    std::cout << s1 << " " << s2;
    return s1[0] + s2[0];
}

int main() {
    std::cout << ("Hello"s, "World\n") + ("What's"s, "Up\n") * ("Nicely"s, "Done\n") << "\n";
    "This"s, "is", " so"s, "cool";
    return 0;
}

/* Output: */
Hello World
What's Up
Nicely Done
25271
This is so cool

Approaching large numbers without this operator

In math, we used to separate large numbers using commas. As we can’t use this approach in C++, we have to use other methods to help us with readability and maintainability issues.

Since C++14 we can use a single quote to split a number into multiple sections (cppreference):


unsigned long long l1 = 18446744073709550592ull; // C++11
unsigned long long l2 = 18'446'744'073'709'550'592llu; // C++14
unsigned long long l3 = 1844'6744'0737'0955'0592uLL; // C++14
unsigned long long l4 = 184467'440737'0'95505'92LLU; // C++14

Another strategy is to use the literal e (or E) followed by a number. This means you multiply the number before e by 10 raised to the power of the number after e. For example:


int a = 10e3; // Equals to: 10,000
float b = 15e-3; // Equals to: 0.015
int c = 15.3e6; // Equals to: 15,300,000

Conclusion

The comma operator is useful for separating commands inside a limited section. However, it’s a highly dangerous operator with non-obvious actions and meanings sometimes. If you see a usage of this comma operator, don’t ignore it and suspect it might cause an unseen problem.

The best practice for this particular operator is to avoid it as much as you can and prefer alternatives as much as possible. This operator can cause real damage, as shown in this article, even with subtle changes in the code.

Special thanks to Yehezkel Bernat & Ellie Bogdanov for reviewing & comments.

This article originally published on my personal blog: C++ Senioreas.

LConst PConst - C++

Coral Kashri — Mon, 17 Jul 2023 09:00:00 +0000

The const keyword is widely used within almost every C++ program. It symbolizes the idea of a constant variable, object, function, and more, and is meant to forbid us from manipulating and changing the content of a memory location within a certain scope. However, as we learned before “There is nothing more deceptive than an obvious fact.” (Sherlock Holmes).

Const Rules

In this article, I won’t dive deeply into the const rules, but just move briefly on const ideas I consider as crucial for the point I want to talk about.

Let’s start with the basic rules of const. The most basic const example is a constant variable:


const int a = 42;

In this example, we initialize a constant integer with a value of 42. Any const variable should be initialized at the creation stage (due to the inability to initialize it later). Once the variable is initialized, there is no way to change it (Well… const_cast but it didn’t get into this article scope).

Const location

const keyword can be written in multiple locations of the type:


const int a = 5;
int const b = 6;

The result is the same, in both cases the variables are constant. However, this ability has a great impact when pointers join the picture.


int val;
const int* a = &val;

In this example, we initialize a mutable (not const) int variable named “val”, and a “const” pointer to it called “a”. Now, I say “const” because it’s only a partial const pointer. here is actually applied only to the pointer’s value, not the pointer itself. which means that we can modify this pointer to point to another variable, but we won’t be able to modify the variable content through this pointer. For example:


int val;
const int* a = &val;

// *a = 5; // Won't compile. The integer content is protected by the const qualifier.

int val2;
a = &val2; // Works just fine.

Now, this also means that we can create the pointer variable without assigning a value to it at the creation stage:


// const val; // doesn't compile
const int* a; // Works.

If we want to protect the pointer, we have to change the const qualifier location. Let’s inspect the different possible locations for the const qualifier in this example:


const int* a; // the int content is being protected.
int const* b; // the int content is being protected.

int val;
int* const c = &val; // the pointer is being protected, and therefore have to be initializes at the creation stage.

We can combine the different const locations as long as they don’t repeat the meaning in the same variable:


int val;
const int* const a = &val; // both the pointer and its content are protected.
int const* const b = &val; // both the pointer and its content are protected.
// const int const c; // Won't compile because the secound const qualifier have the same meaning of the first const qualifier.

The rule is simple if a const is the first qualifier in the type, the const will be applied to the next element of it. Otherwise, it’ll always be applied to the previous component of it.

Side note: A constant pointer equivalent is a reference variable, for example:


int val;
int &a = val;
int *const b = &val;

Variables “a” and “b” here have the same meaning, they are both protecting the pointer from changes.

Class Const Member Functions

Now that we know the rules for constant variables, let’s talk about constant functions.

Constant functions are defined as functions that can not modify a class’s variables. For example:


class A {
public:
    void func() const {
        // a = 5; // Won't compile
    }

private:
    int a;
};

Everything seems great, right? Let’s inspect another case:


class A {
public:
    void func() const {
        // a = &val; // Won't compile
    }

private:
    int *a;
    int val;
};

So far, everything seems just right. If a function is const, the class’s members can not be modified. It’s time to break this rule a little:


class A {
public:
    A() : a(&val) {}

    void func() const {
        *a = 42; // Wait, WHAT?!
    }

private:
    int *a;
    int val;
};

I guess it’s the right time to go back to the quote “There is nothing more deceptive than an obvious fact.” of Sherlock. The constant function only protects the last element of the class’s members’ types. So in this example, we modified a member variable content through a pointer member inside a constant member function.

Marking this function as a const function is a mistake that might lead to bugs if someone will relay on this const qualifier. This function actually performs a hidden const_cast and it shouldn’t. In order to fix this issue, the right thing would be to remove the const qualifier from this function.

Code inspection tools sometimes might advise us to add a const qualifier to this function, because the compiler allows that, but we shouldn’t. Adding a const qualifier to a class’s function should always be done only after careful consideration of whether this function modifies the class’s state/variables or not.

Let’s see an even more confusing example:


class A {
public:
    A() : a(val) {}

    void func() const {
        a = 42; // Oh no...
    }

private:
    int &a;
    int val;
};

This time we even don’t see the * when modifying the content. And it’s not even a UB! It’s totally legal by the language’s standard.

Conclusion

The title LConst PConst stands for Logical Const vs. Physical Const. We should always prefer to use the logical one over the physical one, and the compiler doesn’t help us this time.

I didn’t dive into more aspects of the const qualifier in this article, but I might do it in future articles. If you have a specific request, feel free to contact me on the dedicated channels of this blog like Discord and Telegram.

Feel free to leave your opinions in the comments section.

Into the Extreme – Fold-Expressions

Coral Kashri — Mon, 22 May 2023 09:00:00 +0000

Fold expressions exist in C++ since C++17 and significantly affect how we treat variadic templates. Back in the day, I wrote about fold-expressions as part of the metaprogramming series, but today we will explore the extreme cases of fold-expression usages.

An important disclaimer before we start: In this article, code examples show variadic template usages with arguments passed by value, without forwarding them. This is done to simplify them and to focus on the idea behind the examples.

Empty Variadic Parameters

In the case of a unary fold (fold expression without initialization), this case is legal for 3 types of operators: &&, ||, and ,.

Operator &&


template <typename ...Args>
auto and_cond(Args... args) {
    return (args && ...);
}

In case of empty parameters (for the call and_cond()), the function will return true. A reasonable explanation for this decision might be that && operator requires there won’t be any part that evaluates false. In this case, there are no parts at all, so none of the parts evaluates false, and therefore the result should be true.

Operator ||


template <typename ...Args>
auto or_cond(Args... args) {
    return (args || ...);
}

In case of empty parameters, the function will return false. A reasonable explanation for this decision might be that || operator requires that at least one of the parts will evaluate true. Because there are no parts at all, none of them evaluates true, therefore the result is false.

Operator ,


template <typename ...Args>
auto comma_op(Args... args) {
    return (args , ...);
}

For this case, when there are no parameters passed, the result will be void().

Other operators

For other operators, any call without parameters won’t compile.

Variadic pack with a single parameter

Here things get a little bit unexpected. When passing only one parameter to a variadic pack, the result will ignore the operator and return the same type & parameter sent to the function (Tested on both gcc 13.1.0 & clang 16.0.0). For example:


template <typename ...Args>
auto func(Args ...args)
{
    return (args || ...);
}

int main() {
    using namespace std::string_literals;
    std::cout << func("I am a string"s); // Will print "I am a string"
    return EXIT_SUCCESS;
}

The generated code according to C++ Insights is:


template<>
std::basic_string<char> func<std::basic_string<char>>(std::basic_string<char> __args0)
{
  return std::basic_string<char>(static_cast<std::basic_string<char>&&>(__args0));
}

The same would be for any other operator, including +=, .* and ->.

Binary fold expression without parameters

The same rules for a unary fold expression with a single parameter, are applied to a binary fold expression without parameters:


template <typename ...Args>
auto func(Args ...args)
{
    return (args ->* ... ->* "I am a string"s);
}

int main() {
    std::cout << func(); // Will print "I am a string"
    return EXIT_SUCCESS;
}

C++ Insights generated code:


template<>
std::basic_string<char> func<>()
{
  return std::operator""s("I am a string", 13UL);
}

Conclusion

We have to pay close attention to extreme cases and can never count on basic logic to be on our side (who would believe that we can send a std::string to a fold expression that uses || or && operators?).

This article was inspired by a conversation between Daisy Hollman and me. Thank you Daisy!

An unrelated note: My articles’ publish rate decreased during the last several months. The reason is the preparations for Daisy’s and mine talk in Core C++ (guess which conversation led to this article).

The View of The String

Coral Kashri — Mon, 24 Apr 2023 09:00:00 +0000

Communication is a powerful tool of the humanity. It allows us to transfer ideas and thoughts from one to another. There are many ways of communications, and one of them is words. In order to communicate using words, we need the ability to understand each word in a sentence and to understand the way the words connect with each other. Words analysis today became a major topic in development, and a lot of AI tools trying to perform words analysis (NLP techniques and more). However strings might be painful in some legacy C++ versions (11/14), and the understanding that the language needs some more abilities to handle strings got attention in C++17, with std::string_view.

std::string

Before getting into details of why std::string_view is so important, we need to discuss first about the abilities of std::string.

std::string is basically a friendly wrapper for char*/char[]. It allows us to store a continuous memory allocation of chars, modifying it, iterating, and eventually displaying it. For example:


std::string str = "My str";
std::string prefix = "My ";
if (str.compare(0, prefix.size(), pre) == 0) {
    std::cout << str.substr(prefix.size()); // "str"
}

Now, the compare function seems a little bit of C language, but there is another pitfall here. std::string::substr costs us with another std::string allocation. Because it doesn’t modify the original string instance, it returns a new string instance, which really doesn’t needed here. In order to avoid that we have to do something like that:


for (size_t i = prefox.size(); i < str.size(); ++i) {
    std::cout << str[i];
}

Let’s see another usage example:


bool validate(const std::string& str) {
    std::string start = "lstart", stop = "lstop";
    return str.compare(0, start.size(), start) == 0 && str.compare(str.size() - stop.size(), stop.size(), stop) == 0;
}

Here we don’t have any copies performed. But it’s easy to cause one if forgetting the & sign in the function’s signature. But again, C’s compare syntax.

std::string_view (C++17)

Since C++17 we can use string_view instance, to watch a continuous memory allocation which is already allocated. That means that we can get a sub string view, which supports iterations and comparisons actions, without allocating a new std::string instance for that, and avoiding C syntax, at the same time.


std::string str = "My str";
std::string prefix = "My ";
std::string_view str_v = str; // no allocation performed
if (str_v.substr(0, prefix.size()) == prefix) { // no allocation
    std::cout << str_v.substr(prefix.size()); // no allocation
}

It means that for the validate function we can now simply pass a std::string_view without any need for const & specifiers:


bool validate(std::string_view str) {
    std::string start = "lstart", stop = "lstop";
    return str.substr(0, start.size()) == start && str.substr(str.size() - stop.size()) == stop;
}

How does it work?

std::string_view is actually a structure which contains a pointer to the start of the chars buffer, and a size. This information is passed in the constructors, and extracted to a new instance in substr function. When constructing a std::string_view instance from a std::string instance, we actually using std::string::operator basic_string_view and than constructing a std::string_view from a std::string_view.

One step forward

std::string_view can also be constructed out of a char* instance, or from char* & size_t parameters. That means, that in case we only need to watch and analyse a compile time strings (that are being saved into the binary source, and therefore their addresses are valid to use), we can assign them directly to a std::string_view instance, instead of constructing a std::string instance at first.


std::string_view str = "My str"; // no string allocation
std::string_view prefix = "My ";
if (str.substr(0, prefix.size()) == prefix) {
    std::cout << str.substr(prefix.size());
}
bool validate(std::string_view str) {
    std::string_view start = "lstart", stop = "lstop"; // no string allocations
    return str.substr(0, start.size()) == start && str.substr(str.size() - stop.size()) == stop;
}

* Important to know: when constructing a std::string_view instance out of char* without specifying the length, the length will be defined be the first null character. It’s important to use it carefully. We’ll discuss this issue further.

C++20/23 extensions

New standards brought new useful features to std::string_view and to std::string objects. In C++20 we got two new member functions: strats_with & ends_with (which are perfect for the examples above), and since C++23 we also have contains member function:


std::string_view str = "My str";
std::string_view prefix = "My ";
if (str.starts_with(prefix)) {
    std::cout << str.substr(prefix.size());
}
bool validate(std::string_view str) {
    return str.starts_with("lstart") && str.ends_with("lstop");
}

Constexpr

All of the above functions can be made or used within a constexpr context. Since std::string_view doesn’t allocate any new data, it’s an open window for compile time programming.


constexpr std::string_view str = "My str";
constexpr std::string_view prefix = "My ";
if (str.starts_with(prefix)) {
    std::cout << str.substr(prefix.size());
}
constexpr bool validate(std::string_view str) {
    return str.starts_with("lstart") && str.ends_with("lstop");
}

Bad practices & potential issues

std::string_view designed to allow better performances when analysing strings. However, there is always a trade-off between performances and safety, and that trade-off takes a major place when dealing with std::string_view.

Rule #1: Never return a std::string_view


std::string_view func() {
    std::string str;
    std::cin >> str;
    return str;
}

This innocent function leads to an unsafe memory access. The str is allocating a new place on the heap for the input characters. After returning a std::string_view of this memory, in the destructor it releases the allocated memory. That means that the return std::string_view is now pointing to a released memory.

That being said, returning a std::string_view won’t always cause an unsafe memory access. Cases where the returned std::string_view pointing to a static memory, or to a memory that is accessible outside the function, are still valid, but can become invalid in the future, so the safe way is to forbid returning of std::string_view in any case.

Rule #2: Careful with null terminator

As mentioned before, null terminator is highly not recommended to use, and should always be kept in mind when using std::string_view.


std::string_view str = "my cool str";
str.remove_prefix(str.find(" "));
str.remove_suffix(str.size() - str.rfind(" "));
std::cout << str; // "cool" - OK
std::cout << str.data(); // "cool str"

remove_prefix & remove_suffix only change the start & end point of the view. That means, that the remove_suffix function doesn’t insert a null terminator at the end, so printing the underlying data won’t be affected from it. In order to fix it we can modify the owner string (if such exists) or constructing a std::string from it, so it’ll perform it for us (without modifying the original string).


{ // Modifying owner
    std::string str = "cool str";
    std::string_view str_v = str;
    str_v.remove_suffix(4);
    str[4] = '\0';

    std::cout << str << "\n"; // "cool\0str"
    std::cout << str_v << "\n"; // "cool"
    std::cout << str_v.data(); // "cool"
}

{ // Allocating a new string
    std::string_view str = "cool str";
    str.remove_suffix(4);
    std::string modified_str(str);
    std::string_view mstr_v = modified_str;

    std::cout << str << "\n"; // "cool"
    std::cout << str.data() << "\n"; // "cool str"
    std::cout << modified_str << "\n"; // "cool"
    std::cout << mstr_v << "\n"; // "cool"
    std::cout << mstr_v.data(); // "cool"
}

Rule #3: Don’t lose ownership

It’s important to remember that std::string_view doesn’t own the contained string, and therefore won’t protect or release it. In addition to UB or illegal memory access, it may cause in some cases memory leak (might be caused due to converting an existing code which uses std::string to use std::string_view):


const char* get() { return new char[]{"my new str"}; }

{
    std::string_view str = get();
    // Here we can call: delete str.data()
    str.remove_prefix(1); // Memory leak!
    // delete str.data() // Invalid call here. The pointer doesn't point to the allocated section head.
}

Conclusion

std::string_view can be used to optimize both performance and readability in code sections which handle strings. However any usage comes with an additional responsibility to use it in the correct way, and avoiding unwanted behavior (especially on scaling and when code modifications enter to the picture). It is another example for a case when a great power is followed by a great responsibility.

The Number that Broke and Spoke – C++ Investigator

Coral Kashri — Tue, 13 Oct 2020 10:30:00 +0000

How many times you find yourself writing hard-coded numbers inside your code, while trying to make sure as much as you can to make these numbers' units visible? You probably found yourself mentioning the units as part of the variable name, or at the comment, praying that who ever gets to your code will understand it. After reading this article, you will have the most maintainable way of doing so.

Numbers Attack

It was 2 am when I got a really bad feeling. I knew that something just happened to that patch I created the day before. All I done was to add the following function:

void delay(float milliseconds) { ... }

In the morning, I ran into the office and checked the recent changes. This is what I saw:

/*void delay_m(float minutes);
void delay_s(float seconds);
void delay_millis(float milliseconds);
void delay_micros(float microseconds);
void delay_ns(float nanoseconds);*/

// ... A class function ...
    float initial_delay_ns = 1000;
    delay_ns(initial_delay_ns);
    // ...
    float increased_delay_s = 1;
    delay_s(increased_delay_s);
    // ...
    auto current_delay_ns = initial_delay_ns + increased_delay_s * 1e9;
    auto wait_time_m = 2.65;
    delay_m(wait_time_m);
    // ...
    std::cout << "Total delay: " << current_delay_ns + wait_time_m * 60 * 1e9 << std::endl;
// ...

Well, it can't stay this way. The code looks like an active crime scene.

Bring Numbers to Justice

Those numbers won't speak a single word without their lawyers- the variables. We need to find a way to make them talk even when their layers are out for business. I decided to hire a consultant - cppreference. After some days she sent me the following message:

Hi there.
I heard some words about a way to mark your numbers, so you'll be able to treat them in any way you want to. This mark can leave them as they are and can even transform them into a different type.

Note: This ability also relevant for chars and chars array.

It's called User-defined literals.

Sincerely yours,
cppreference.

User-defined literals

This feature makes it possible to mark with a suffix numbers, chars and strings, so they'll be more informative and understandable. This mark will produce a different object, that we'll define.

Before we go deeper into syntax and rules, let's see how the above example would look with user-defined literals:

// void delay(std::chrono::nanoseconds) {}
// ...
    using namespace std::literals::chrono_literals;
    auto initial_delay = 1000ns;
    delay(initial_delay);
    // ...
    auto increased_delay = 1s;
    delay(increased_delay);
    // ...
    auto current_delay = initial_delay + increased_delay;
    auto wait_time = 3min;
    delay(std::chrono::duration_cast<std::chrono::nanoseconds>(wait_time));
    // ...
    std::cout << "Total delay: " << std::chrono::duration_cast<std::chrono::seconds>(current_delay + wait_time).count() << " seconds." << std::endl;
// ...

Syntax

In order to create new user-defined literals, regardless what the standard offer to us, we have to use the following syntax:

[constexpr] [inline] out_type operator"" _suffix(in_type);

out_type - Can be any type you need.
suffix - The characters you want (There are several rules which apply here, for the simplicity always start with a lowercase letter. for a further reading: cppreference - user literal).
in_type - Only the following parameter lists are allowed:
- const char*
- unsigned long long int
- long double
- char
- wchar_t
- char8_t (sice C++20)
- char16_t
- char32_t
- const char*, std::size_t
- const wchar_t*, std::size_t
- const char8_t* , std::size_t
- const char16_t* , std::size_t
- const char32_t* , std::size_t
In case that the function is a template function, it must have an empty parameter list and it must be a non-type template with the following restrictions:

- The template is a non-type template parameter pack with element type char:

template <char...> out_type operator"" _suffix();

- Since C++20 it can be also a non-type template parameter of class type (in which case it is known as a string literal operator template):

struct A { constexpr A(const char *); };
template<A a> A operator"" _a();

Standard Library Main Literals

How To Use?

In order to use the standard user-defined literals, we have to use using namespace std::;. Without it the syntax would look like this:

auto str = std::string_literals::operator""s("aaa", 3);
// Instead Of: auto str = "aaa"s;

Usually, we don't get to see this kind of syntax, even when we don't use using namespace ... which usually considered as a bad practice, so why do we need it here?

The answer for this question is ADL (Argument-dependent lookup), which I won't be able to cover on this article. Make a long story short: The compiler can identify a function namespace if one of the parameters that sent to this function comes from the same namespace (e.g. std::cout).

String Literals

using namespace std::string_literals;

The user-defined literals we get from this namespace are std::string_literals::operator""s which accepts the following parameters:

const char* __str, size_t __len
const wchar_t* __str, size_t __len
const char8_t* __str, size_t __len
const char16_t* __str, size_t __len
const char32_t* __str, size_t __len

Each on of them will return a std::basic_string object of the specified type. For example:

auto str = "Hello String Literals"s;

Will make str of type std::basic_string which is the same as std::string. This one is a very common usage of user-defined literals.

Chrono Literals

using namespace std::chrono_literals;

Chrono literals return a std::chrono::duration object. It supplies the following user-defined literals: h [hours], min [minutes], s [seconds], ms [milliseconds], us [microseconds], ns [nanoseconds], y [A specific year in the range: (-32767, 32767)], d [Representing a day of a month in the calendar (legal only for values lower than 256)].

A usage example you can find in the first user-defined literals example in this article.

Complex Literals

using namespace std::literals::complex_literals

Complex literals will return a given number as an imaginary part with real part initialized to zero. Available user-defined literals:

i - returns std::complex(0, arg);
if - returns std::complex(0, arg);
il - returns std::complex(0, arg);

int main() {
    using namespace std::complex_literals;
    std::complex<double> c = 1.0 + 1i; // std::complex<double>(1.0, 1.0)
    std::complex<float> z = 3.0f + 4.0if; // std::complex<float>(3.0, 4.0)
}

User-Defined Literals Example

Angles Example

class angle {
public:
    struct degrees {};
    struct radians {};
    constexpr angle(float deg, degrees) { _deg = deg; }
    constexpr angle(float rad, radians) { _deg = rad * 180 / M_PI; }
    [[nodiscard]] constexpr float get_degrees() const { return _deg; }
    [[nodiscard]] constexpr float get_radians() const { return _deg * M_PI / 180; }

private:
    float _deg;
};

namespace literals {
    constexpr angle operator"" _deg(long double deg) {
        return angle(deg, angle::degrees{});
    }

    constexpr angle operator"" _deg(unsigned long long int deg) {
        return angle(deg, angle::degrees{});
    }

    constexpr angle operator"" _rad(long double rad) {
        return angle(rad, angle::radians{});
    }

    constexpr angle operator"" _rad(unsigned long long int rad) {
        return angle(rad, angle::radians{});
    }
}

using namespace literals;

int main() {
    constexpr auto deg = 3.14159265_rad;
    constexpr auto rad = 360_deg;
    static_assert(deg.get_degrees() == 180);
    static_assert(rad.get_radians() == (float)(M_PI * 2));
    std::cout << deg.get_degrees() << std::endl; // 180
    std::cout << deg.get_radians() << std::endl; // 3.14..
    std::cout << rad.get_degrees() << std::endl; // 360
    std::cout << rad.get_radians() << std::endl; // 6.28..
    return EXIT_SUCCESS;
}

Dates Example

Based on dates example from Become a Compile-Time Coder.

struct date_offset {
    int d;
    int m;
    int y;

    constexpr date_offset(int days, int months, int years) : d(days), m(months), y(years) {}

    [[nodiscard]] constexpr date_offset operator+(date_offset ref) const {
        return date_offset(d + ref.d, m + ref.m, y + ref.y);
    }

    [[nodiscard]] constexpr date_offset operator-(date_offset ref) const {
        return *this + date_offset(-ref.d, -ref.m, -ref.y);
    }
};

class date {
public:
    constexpr date(int day, int month, int year)
            : d(day), m(month), y(year) {
        self_balance();
    }

    [[nodiscard]] constexpr date offset(date_offset offset_data) const {
        const auto after_years_offset = date(d, m, y + offset_data.y);
        const auto after_month_offset = date(d, m + offset_data.m, after_years_offset.get_year());
        return date(after_month_offset.get_day() + offset_data.d, after_month_offset.get_month(), after_month_offset.get_year());
    }

    [[nodiscard]] constexpr date operator+(date_offset offset_data) const {
        return offset(offset_data);
    }

    [[nodiscard]] constexpr unsigned short get_day() const { return d; }
    [[nodiscard]] constexpr unsigned short get_month() const { return m; }
    [[nodiscard]] constexpr unsigned short get_year() const { return y; }

private:
    int d, m, y;

    constexpr void self_balance() {
        unsigned short days_in_month;
        unsigned short days_in_prev_month = 31;
        bool is_change_detected = false;
        if (m == 2) {
            if (!(y % 4)) {
                days_in_month = 29;
            } else {
                days_in_month = 28;
            }
        } else {
            if (m <= 7 &amp;&amp; m % 2 || m >= 8 &amp;&amp; m % 2 == 0) {
                days_in_month = 31;
                if (m != 8) {
                    days_in_prev_month = 30;
                }
            } else {
                days_in_month = 30;
            }
        }

        if (d > days_in_month) {
            d -= days_in_month;
            m++;
            is_change_detected = true;
        } else if (d < 1) {
            d += days_in_prev_month;
            m--;
            is_change_detected = true;
        }

        if (m > 12) {
            m = 1;
            y++;
            is_change_detected = true;
        } else if (m < 1) {
            m = 12 - m;
            y--;
            is_change_detected = true;
        }

        if (is_change_detected) self_balance();
    }
};

namespace literals {
    inline namespace dates_literals {
        constexpr date_offset operator"" _d(unsigned long long int days) {
            return date_offset(days, 0, 0);
        }

        constexpr date_offset operator"" _m(unsigned long long int months) {
            return date_offset(0, months, 0);
        }

        constexpr date_offset operator"" _y(unsigned long long int years) {
            return date_offset(0, 0, years);
        }
    }
}

using namespace literals;

int main() {
    constexpr date my_date(23, 8, 2020);
    constexpr auto new_date = my_date + 8_d + 3_m + 5_y;
    std::cout << new_date.get_day() << " / " << new_date.get_month() << " / " << new_date.get_year() << std::endl;
    static_assert(new_date.get_day() == 1 && new_date.get_month() == 12 && new_date.get_year() == 2025);
    return EXIT_SUCCESS;
}

Summarize

A number without a literal is just a number without any meaning, and it makes the code really hard to maintain in the long term. We can use user-defined literals in order to control conversions between units, and this way we can significantly reduce our code complexity and reduce the chances for units conversion mistakes.

This article originally published on my personal blog: C++ Senioreas

Full examples repository: cppsenioreas-user-defined-literals

Template Base Class Collection

Coral Kashri — Sun, 30 Aug 2020 10:30:00 +0000

When designing an architecture you might come across a need to create a collection of a template class. At first it'll sound easy, but soon you'll find that it's almost impossible to archive. At the end of this article, you'll be able to archive the impossible.

Previous article in series: Substitution Failure is Not an Error – SFINAE

The Problem

A little reminder from a previous article [templates infinity theory - part 1] for the shape class (with an additional shape name):

template <typename ...Properties> // Variadic Template
class shape : virtual public Properties... { // Multiple properties inheritances, the virtual will be more significant in the future
public:
    explicit shape(std::string name) : name(std::move(name)) {}
    virtual ~shape() = default;
    virtual void input_data() { (Properties::input_data(), ...); }
    [[nodiscard]] virtual double area() const = 0;
    [[nodiscard]] std::string get_name() const { return name; }
protected: std::string name;
};

After we designed our shape base class, we created some different shapes with different properties (this is a shortcut, for the full example please refer to the original article with this example):

class rectangle : public shape<width_shape_property, height_shape_property> {
public:
    rectangle() : shape("Rectangle") {}
    void input_data() override { std::cout << "Input " << name << ":" << std::endl; shape::input_data(); }
    [[nodiscard]] double area() const override { return width * height; }
};

class triangle : public shape<width_shape_property, height_shape_property> {
public:
    triangle() : shape("Triangle") {}
    void input_data() override { std::cout << "Input " << name << ":" << std::endl; shape::input_data(); }
    [[nodiscard]] double area() const override { return (width * height) / 2; }
};

class circle : public shape<radios_shape_property> {
public:
    circle() : shape("Circle") {}
    void input_data() override { std::cout << "Input " << name << ":" << std::endl; shape::input_data(); }
    [[nodiscard]] double area() const override { return M_PI * radios * radios; }
};

Now we might want to create a collection to contain different shapes, they all inherit from the same class after all:

int main() {
    std::vector<std::shared_ptr<shape>> shapes;
    return EXIT_SUCCESS;
}

And... We got an error, which is basically saying "Which shape vector do you want to create?". Well, it didn't go so easy. To understand it, we need to understand the issue.

shape is not a class, it's a template class. Every specialization will be an unrelated, independent class, which means we can't contain them under the same pointer type. Moreover different specializations might not implement the same interface:

template <typename T>
class base {
public:
    void func() {}
};

template<>
class base<int> {
public:
    void my_func() {} // No func here!
}

template<>
class base<double> {
public:
    double func; // func here is a class member variable
}

Now, with the understanding that we need to create a shared interface, which will hold for every specialization we'll create, it is the right time to build our solution.

The Solution

Note: In 2013 Sean Parent published a presentation that this solution is based on: Inheritance Is The Base Class of Evil.

Let's start with easy steps before we get to the most generic solution. We understood that we can't create a shared template interface with a guarantee that it'll really stay a "shared". So let's separate our base template class from the actual interface:

class shape_interface {
public:
    virtual ~shape_interface() = default;
    virtual void input_data() = 0;
    [[nodiscard]] virtual double area() const = 0;
};

class shape_property {
public:
    virtual void input_data() = 0;
};

template <typename T>
concept ShapeProperty = std::is_base_of_v<shape_property, T>;

template <ShapeProperty ...Properties>
class shape : public shape_interface, virtual public Properties... {
public:
    explicit shape(std::string name) : name(std::move(name)) {}
    virtual ~shape() = default;
    void input_data() override { (Properties::input_data(), ...); };
    [[nodiscard]] std::string get_name() const { return name; }
protected: std::string name;
};

With this shape_interface we can now create a vector which will hold our shapes:

int main() {
    std::vector<std::shared_ptr<shape_interface>> vec;

    vec.emplace_back(std::make_shared<rectangle>());
    vec.emplace_back(std::make_shared<triangle>());
    vec.emplace_back(std::make_shared<circle>());

    return EXIT_SUCCESS;
}

Hooray! It worked just like any other interface! Let's go home and drink a cold beer!

When you woke up in the morning with a little headache, you noticed a new email from work:

Hi there, I'm Bob, a coworker of you.
I saw your solution for the shapes, and I loved it!
However, I just found a library which offers a lot of shapes with a similar interface. It has the same methods with some extra, so I thought it might be nice thing to include their shapes as well.
One issue: I can't see their source code, so I can't modify their interface. Any ideas how to solve this issue?
Cheers, Bob.

The first thought that came to your mind is: Did he have to use "Cheers"? The second one is why the hell did he find this library?? So you came back to your work and started to think about the new situation.

You have a new class that implements the same functionality you required in your interface, but it simply uses another one:

class independent_legal_shape : another_interface {
public:
    independent_legal_shape() = default;

    void input_data() {
        std::cout << "No input needed for independent_legal_shape." << std::endl;
    }

    [[nodiscard]] double area() const {
        return 50;
    }
};

int main() {
    std::vector<std::shared_ptr<shape_interface>> vec;

    vec.emplace_back(std::make_shared<rectangle>());
    vec.emplace_back(std::make_shared<triangle>());
    vec.emplace_back(std::make_shared<circle>());
    // vec.emplace_back(std::make_shared<independent_legal_shape>()); // Obviously that won't compile

    return EXIT_SUCCESS;
}

Suddenly, out of the blue, an idea came to your mind: What about creating a container which will hold any type and just call its methods of the desired interface. Something like that:

template <typename T>
class shape_interface_implementation : public shape_interface {
    T&amp; m_impl_obj; // Contain the target specialized class instance

public:
    explicit shape_interface_implementation(T&amp; impl_obj) : m_impl_obj(impl_obj) {}

    // Interface should be fully implemented here
    // region [Interface Implementation Begin]
    void input_data() override { return m_impl_obj.input_data(); };
    [[nodiscard]] double area() const override { return m_impl_obj.area(); };
    // endregion [Interface Implementation End]
};

Now your main will look like that:

int main() {
    std::vector<std::shared_ptr<shape_interface>> vec;
    rectangle r; triangle t; circle c; independent_legal_shape my_shape;

    vec.emplace_back(std::make_shared<shape_interface_implementation<rectangle>>(r));
    vec.emplace_back(std::make_shared<shape_interface_implementation<triangle>>(t));
    vec.emplace_back(std::make_shared<shape_interface_implementation<circle>>(c));
    vec.emplace_back(std::make_shared<shape_interface_implementation<independent_legal_shape>>(my_shape));

    return EXIT_SUCCESS;
}

It works, but something feels a little bit fishy here. It looks a lot more complicated than it was before, and something tells you that it can be simplified. A little search around the web, and you find a short video of Sean Parent: Inheritance Is The Base Class of Evil. There he presented a wrapper class which holds the pointer to the interface inside it. With little modifications to hold a direct access to the objects of the wrapper, you get the following wrapper class:

class template_base_shape_container {
public:
    template <typename T>
    explicit template_base_shape_container(T &amp;obj) : m_obj(std::make_shared<interface_implementation<T>>(obj)) {}

    // Get a pointer to the interface implementation
    std::shared_ptr<shape_interface> get() { return m_obj; }

private:
    template <typename T>
    class shape_interface_implementation : public shape_interface { // The exact same interface_implementation as before
        T&amp; m_impl_obj; // Contain the target specialized class instance

    public:
        explicit shape_interface_implementation(T&amp; impl_obj) : m_impl_obj(impl_obj) {}

        // Interface should be fully implemented here
        // region [Interface Implementation Begin]
        void input_data() override { return m_impl_obj.input_data(); };
        [[nodiscard]] double area() const override { return m_impl_obj.area(); };
        // endregion [Interface Implementation End]
    };

    std::shared_ptr<shape_interface> m_obj; // Inner pointer
};

int main() {
    std::vector<template_base_shape_container> shapes;
    rectangle r; triangle t; circle c; independent_legal_shape my_shape;

    shapes.emplace_back(r);
    shapes.emplace_back(t);
    shapes.emplace_back(c);
    shapes.emplace_back(my_shape);

    return EXIT_SUCCESS;
}

Looks even better than the simple shared interface. The only change is the access which now looks like that:

for (auto &amp;shape : shapes) {
    shape.get()->input_data();
    std::cout << shape.get()->area() << std::endl;
}

Another day past with a success, but this time you don't risk yourself with a beer. You fall asleep wishing to wake up without any new work emails. When you wake up, surprisingly no new emails. You come to another work day, happy that you completely solved the issue, but then it hit you. You look at the nice code you left the other day, and you just can't believe it. New 10 wrapping classes which look exactly the same, with a single change: The Interface [Coming Soon at IMDb]. Let's make the container a generic container!

// A generic interface implementation
template <typename Interface, typename T>
class interface_implementation : public Interface {
public:
    explicit interface_implementation(T&amp; impl_obj) : m_impl_obj(impl_obj) {}

    // Interface should be fully implemented here
    // region [Interface Implementation Begin]
    // endregion [Interface Implementation End]

private:
    T&amp; m_impl_obj; // Contain the target specialized class instance
};

// A generic template base container to match any future interface
template <typename Interface>
class template_base_container {
public:
    template <typename T>
    explicit template_base_container(T &amp;obj) : m_obj(std::make_shared<interface_implementation<Interface, T>>(obj)) {
        static_assert(std::is_base_of_v<Interface, interface_implementation<Interface, T>>, "In template_base_container interface_implementation<Interface, T> should inherit from Interface template param.");
    }

    // Get a pointer to the interface implementation
    std::shared_ptr<Interface> get() { return m_obj; }

private:
    std::shared_ptr<Interface> m_obj;
};

And for the interface specialization:

// Interface implementation specialization for shape_interface
template <typename T>
class interface_implementation<shape_interface, T> : public shape_interface {
public:
    explicit interface_implementation(T&amp; impl_obj) : m_impl_obj(impl_obj) {}

    // Interface should be fully implemented here
    // region [Interface Implementation Begin]
    void input_data() override { return m_impl_obj.input_data(); };
    [[nodiscard]] double area() const override { return m_impl_obj.area(); };
    // endregion [Interface Implementation End]

private:
    T&amp; m_impl_obj; // Contain the target specialized class instance
};

Our main stays without a change:

int main() {
    std::vector<template_base_container<shape_interface>> shapes;
    rectangle r; triangle t; circle c; independent_legal_shape my_shape;

    shapes.emplace_back(r);
    shapes.emplace_back(t);
    shapes.emplace_back(c);
    shapes.emplace_back(my_shape);

    for (auto &amp;shape : shapes) {
        shape.get()->input_data();
        std::cout << shape.get()->area() << std::endl;
    }

    return EXIT_SUCCESS;
}

Conclusion

Templates and inheritances combinations are a huge topic with almost infinite possibilities in C++. This is the time to thank for Sean Parent for his "Inheritance Is The Base Class of Evil" amazing talk, that without it this article wouldn't be made.

Feel free to share your experience with templates & inheritances here, and if you see any improvements that can made to make this container even more generic or written with less code duplications (e.g. interface_implementation have a code duplication for every specialization).

Updated repository for template_base_container: common_template_base

This article originally published on my personal blog: C++ Senioreas

C++ Basic templates usage – Part 2

Coral Kashri — Thu, 30 Jul 2020 14:21:53 +0000

This is the third article in the series of meta programming tutorials. Here we’ll see more basic usage of templates in C++. In this part I’ll talk about non-type template parameters, template of templates, and about passing a function as a template argument.

Next post on series: C++ templates – Beginners most common issue

Non-Type Template Parameters

So far we saw a type template parameter, which is basically means that the function/class specializations are differed by a type/s that passed as a template parameter/s (e.g. int, float, double, std::string, etc...). So what does a non-type template parameter means?

A template that accepts one of the following types:

lvalue reference
nullptr_t
pointer
enumerator
integral

Integral

std::array

Probably the most famous usage for a non-type template parameter is for std::array. std::array accepts two template parameters: array type (type parameter) & array size (non-type parameter). Example:

std::array<int, 5> arr;

As you can see, the array size is defined at compile time, and can't be changed during run-time. It might get annoying when you try to create a function that accept the arrays you are working with, when the arrays are deffer in their sizes:

void my_array_func(std::array&lt;int, 5> &amp;arr); // Accepts integer arrays with size 5.
void my_array_func(std::array&lt;int, 6> &amp;arr); // Accepts integer arrays with size 6.
void my_array_func(std::array&lt;int, 7> &amp;arr); // Accepts integer arrays with size 7.

To go around this issue, we should use a non-type template parameter in this function:

template <size_t N>
void my_array_func(std::array<int, N> &arr); // Accepts any integers array.

Or even in a more generic way:

template <typename T, size_t N>
void my_array_func(std::array<T, N> &arr); // Accepts any array.

Compile-Time Mathematics Expressions

Another famous use-case for non-type template parameter are compile-time mathematics expressions calculation.

namespace math {

    /* Factorial */
    template <size_t N>
    struct factorial {
        static constexpr auto val = N * factorial<N - 1>::val;
    };

    template <>
    struct factorial<1> { // Partial specialization will be discuss in a future post in this series
        static constexpr auto val = 1;
    };

    /* Pow */
    template <size_t Base, size_t N>
    struct pow {
        static constexpr auto val = Base * pow<Base, N - 1>::val;
    };

    template <size_t Base>
    struct pow<Base, 0> { // Partial specialization will be discuss in a future post in this series
        static constexpr auto val = 1;
    };
}

int main() {
    std::cout << math::factorial<5>::val << std::endl; // Output 120
    std::cout << math::pow<2, 10>::val << std::endl;   // Output 1024
    return EXIT_SUCCESS;
}

The important thing to understand, is that from run-times perspective, the above main would be equivalent to the following one:

int main() {
    std::cout << 120 << std::endl;
    std::cout << 1024 << std::endl;
    return EXIT_SUCCESS;
}

Let's take the factorial for example to explain how does it work:

At first, the compiler instantiate math::factorial<5>, but to complete it's val, it should take math::factorial<5 - 1>.
The compiler instantiate math::factorial<4>, but to complete it's val, it should take math::factorial<4 - 1>.
The compiler instantiate math::factorial<3>, but to complete it's val, it should take math::factorial<3 - 1>.
The compiler instantiate math::factorial<2>, but to complete it's val, it should take math::factorial<2 - 1>.
factorial<1> already specialized, so the recursion can now collapse.
factorial<2>::val is 2 * factorial<1>::val, which is equal to 2.
factorial<3>::val is 3 * factorial<2>::val, which is equal to 6.
factorial<4>::val is 4 * factorial<3>::val, which is equal to 24.
factorial<5>::val is 5 * factorial<4>::val, which is equal to 120.

Enumerator

The following is a simple example, to print enum values at compile time:

enum languages {
    CPP,
    C,
    CSHARP,
    JAVA,
    ASSEMBLY
};

template <languages Lang>
constexpr auto stringify() {
    if constexpr (Lang == CPP) {
        return "C++ language";
    } else if constexpr (Lang == C) {
        return "C language";
    } else if constexpr (Lang == CSHARP) {
        return "C# language";
    } else if constexpr (Lang == JAVA) {
        return "Java language";
    } else if constexpr (Lang == ASSEMBLY) {
        return "Assembly language";
    }
}

int main() {
    std::cout << stringify<CPP>(); // C++ language
    return EXIT_SUCCESS;
}

Pointers

You can send pointer as a non-type template parameter, as long as it's address is known at compile-time. It's true for static variables:

template<int* T>
int func(int t) {
    return (*T)++ + t;
}

int main() {
    static int a = 6;
    std::cout << func<&a>(6) << std::endl; // Prints 12
    std::cout << func<&a>(6) << std::endl; // Prints 13

    return EXIT_SUCCESS;
}

Template pointers are usually used to pass another member function as an interface to a class/function:

class general_class {
public:
    void func1() {
        std::cout << __PRETTY_FUNCTION__ << std::endl;
    }

    void func2() {
        std::cout << __PRETTY_FUNCTION__ << std::endl;
    }
};

template<typename T, void (T::*interface)()> // The interface requires a function which returns void and accepts no params.
class interface_required {
public:
    interface_required(T* object) : object(object) {}
    void func() {
        (object->*interface)();
    }

private:
    T *object;
};

Now we can call `interface_required` with both of `general_class` function, a single function per instance:

int main() {
    general_class gc;
    interface_required<general_class, &general_class::func1> ir(&gc);
    interface_required<general_class, &general_class::func2> ir2(&gc);
    ir.func(); // void general_class::func1()
    ir2.func(); // void general_class::func2()

    return EXIT_SUCCESS;
}

Another advantage of this usage is that there is less overhead in the call to this object's function. It's like calling a function and not to a member function.

lvalue reference

The same rule for pointers also applied here- the variable address should be known at compile-time.

template<int& T>
int func(int t) {
    return T++ + t;
}

int main() {
    static int a = 6;
    std::cout << func<a>(6) << std::endl; // Prints 12
    std::cout << func<a>(6) << std::endl; // Prints 13

    return EXIT_SUCCESS;
}

nullptr_t

we we'll discuss this in a future post, it's part of more advanced meta-programming topic.

Template of Templates

An important thing to mention, is that this ability usually doesn't really necessary to use, however it might make to code easier to write and to understand, so don't avoid a friendship with it.

Sometimes, especially when writing a library, it's important to make the code as generic as possible, and we don't want to limit library users to use a specific container type (e.g. std::vector, std::set, std::list, etc..). There are many ways to archive this generic target, and the following example is one of them:

#include <numeric>
#include <vector>

template <typename Cont>
auto sum(Cont &container) {
    typedef typename Cont::value_type T;
    return std::accumulate(std::begin(container), std::end(container), T(0));
}

int main() {
    std::vector<int> vec = {1, 2, 3, 4, 5, 6};
    int res = sum(vec); // Use compiler deduction
    // int res = sum<std::vector<int>>(vec);
    return EXIT_SUCCESS;
}

It worked, and I'll expend the talk about `auto` in a future post in this series (for now it's a type that deduced at compile time by it's first usage). But there is a line that made this simple code to a very unpleasant:
`typedef typename Cont::value_type T;`
It seems that there have to be a better way to get this type. Let's use template of templates:

#include <numeric>
#include <vector>

template <typename T, template<typename, typename = std::allocator<T>> class Cont> // Since C++17 the class can be also a typename
T sum(Cont<T> &container) {
    return std::accumulate(std::begin(container), std::end(container), T(0));
}

int main() {
    std::vector<int> vec = {1, 2, 3, 4, 5, 6};
    int res = sum(vec); // Use compiler deduction
    // int res = sum<std::vector, int>(vec);
    return EXIT_SUCCESS;
}

This line disappeared and we still got the same result. So all we have to do now is to inspect the template line:

template <typename T, template<typename, typename = std::allocator<T>> class Cont>

typename T - will represent the type that the container will contain.
template<typename, typename = std::allocator<T>> - The first type will accept our T, and the second is required for the standard library (std) containers, and by default (which we'll use) is the standard allocator of T (as we do most of the times we use the standard containers.
class Cont - It's the name of the template param type. Until C++17, we had to use the class keyword for these cases of templates-templates, however since C++17 we can still use typename as following:

template <typename T, template<typename, typename = std::allocator<T>> typename Cont>

Most of the necessary usages of templates-templates is on structs/classes with variadic template parameters (don't panic!), but here is a rare case when you have to use it on function:

template <typename OutContType, template <typename, typename> class C, typename InContType>
auto cast_all(const C<InContType, std::allocator<InContType>> &c) {
    C<OutContType, std::allocator<OutContType>> result(c.begin(), c.end());
    return result;
}

int main() {
    std::vector<double> double_vec = {1.5, 2.3, 3.6};
    std::vector<int> int_vec;
    int_vec = cast_all<int>(double_vec);
    // cast_all<int, std::vector, double>(double_vec);
    return EXIT_SUCCESS;
}

A simple casting from one container type to the same container of another type, and you have to pass the container as template of template, or else you won't be able to use the container for another type.

A simplification of this function I'll show in a future post about variadic template parameters.

Passing Function as a Template Argument

This section is only a spoiler for a future post about variadic template parameters, just to prepare you to this subject.

Passing function pointer to another function is something that came all the way from the procedural C language:

void qsort (void* base,
            size_t num,
            size_t size,
            int (*comparator)(const void*,const void*));

In C++, since C++11 (or using boost::function for earlier C++ versions), there is std::function that make the syntax more readable:

std::function<int(void*, void*)> &&comparator

The main issue with this call is the performances. There is an overhead when calling a function with a std::function parameter. To avoid this overhead, we can pass a function as a template parameter:

template<typename FuncT>
int max(std::vector<int> vec, FuncT &&comparator) {
    int res = vec[0];
    for (auto &elem : vec)
        if (comparator(res, elem) < 0)
            res = elem;
    return res;
}

Now that we have a generic fucntion parameter, let's make out function generic too:

template<typename Cont, typename FuncT>
auto max(Cont container, FuncT &&comparator) {
    auto res = *std::begin(container);
    for (auto &elem : container)
        if (comparator(res, elem) < 0)
            res = elem;
    return res;
}

int main() {
    std::vector<int> int_vec = {1, 30, 20, 10};
    std::list<double> double_list = {5.2, 2.9, 6.3, 4.8};
    // Since C++20 template params are allowed in lambda expressions. Since C++14 we can also use `auto`, but here `auto` is too generic for this function.
    auto comp = [] <typename T> (T n1, T n2) -> auto {
        return n1 - n2;
    };
    std::cout << max(int_vec, comp) << std::endl;
    std::cout << max(double_list, comp) << std::endl;
    return EXIT_SUCCESS;
}

Conclusion

I hope you learned something new from the second part of basic generic usage of templates. From now on we are going deeper into the meta-programming subjects, and we'll see more abilities and more usages of meta-programming in modern C++.

Have something unclear? A request for a future post? Want to share new things you learned? Feel free to share!

This post originally published on my personal blog: C++ Senioreas.

C++ Basic templates usage – Part 1

Coral Kashri — Sun, 26 Jul 2020 21:00:00 +0000

This is the second article in the series of meta programming tutorials. Here we'll see a very basic usage of templates in C++. Due to the amount of content that fits into the basic usage of templates, I separated this article into 2 parts. In this part I'll talk about the usage in functions & classes, and about how the compiler handle them.

Next post on series: Basic templates usage – Part 2

Generic Functions

Assume you have the following function:

int sum(int num1, int num2) { return num1 + num2;}

Now you might want to apply the exact same functionality for float & double:

float sum(float num1, float num2) {
    return num1 + num2;
}

double sum(double num1, double num2) {
    return num1 + num2;
}

The code just got 3 times expanded. This is where the templates come to our help. Templates give us the option to accept any type, and to apply the same algorithms for all of them (in future posts I’ll show how to make the compiler choose between different algorithms for different types in the same function, but for now- same algorithm different types). Let’s have a look on templates in action:

template <typename T>
T sum(T num1, T num2) {
    return num1 + num2;
}

int main() {
    int n1, n2;
    float n3, n4;
    double n5, n6;
    std::string a, b;

    n1 = 1; n2 = 2;
    n3 = 3.5f; n4 = 4.3f;
    n5 = 5.2; n6 = 6.1;
    a = "Hello "; b = "World";
    std::cout << sum<int>(n1, n2) << std::endl; // Prints 3 
    std::cout << sum<float>(n3, n4) << std::endl; // Prints 7.8
    std::cout << sum<double>(n5, n6) << std::endl; // Prints 11.3
    std::cout << sum<std::string>(a, b) << std::endl; // Prints "Hello World". Note: From the function's name it's clearly that this isn't the expected usage, but the compiler doesn't know it. We'll see in future posts how to handle such cases.

    return EXIT_SUCCESS;
}

How Does It Work?

For every new call type to the template function, the compiler generates a new function specialization with the new types (since the types are known at compile time). For example, in our case the compiled code will look something like this:

template <typename T>
T sum(T num1, T num2) {
    return num1 + num2;
}

// Integer specialization
template<>
int sum<int>(int num1, int num2) {
    return num1 + num2;
}

// Float specialization
template<>
float sum<float>(float num1, float num2) {
    return num1 + num2;
}

// Double specialization
template<>
double sum<double>(double num1, double num2) {
    return num1 + num2;
}

// std::string specialization
template<>
std::string sum<std::string>(std::string num1, std::string num2) {
    return num1 + num2;
}

// ... main ...

Function Specializations Deduction

In simple cases, when the compiler is able to automatically deduce the function template types just from the passed parameters, we don’t have to explicitly specify the types. For example, we could call sum this way:

int main() {
    /* ... Variable Declarations ... */

    std::cout << sum(n1, n2) << std::endl; // Prints 3 
    std::cout << sum(n3, n4) << std::endl; // Prints 7.8 
    std::cout << sum(n5, n6) << std::endl; // Prints 11.3 
    std::cout << sum(a, b) << std::endl; // Prints "Hello World".

    return EXIT_SUCCESS;}

Generic Classes

The basic templates usage in classes is similar to the functions one. Assume you have a class that handles an integer

class my_class {
public:
    explicit my_class(int val) : m_val(val) {}
    void print_val() const { std::cout << m_val << std::endl; }
    [[nodiscard]] int get() const { return m_val; }
    void set(int val) { m_val = val; }

    int m_val;
};

Now, to make this function also handle a float, double, std::string, and char, you’ll have to create 4 more separate classes, with 4 different names.

Why can’t you just create 4 different classes with the same name, like we did with the functions?

unlike functions, there is no such a thing “class overloading”, for a simple reason: At compile time, the compiler don’t know which class you refer to, and which class you want to create. The error you’ll get for trying define the same class name twice or more: “Redefinition of 'class_name'”.

To archive a single class that handle a single variable of different type every time you have several options:

Use templates.
Use std::variant (which is also implemented using template).

I'll show here the solution using templates, because std::variant is not in the scope of this series (I might talk about it in a future independent post).

template <typename T>
class my_class {
public:
    explicit my_class(T val) : m_val(val) {}
    void print_val() const { std::cout << m_val << std::endl; }
    [[nodiscard]] T get() const { return m_val; }
    void set(T val) { m_val = val; }

    T m_val;
};

int main() {
    my_class<int> mc_i(5);
    my_class<double> mc_d(3.6);

    return EXIT_SUCCESS;
}

Class Specializations Behind The Scenes

Same as in the functions, for every new type usage of this class, the compiler will generate a complete class specialization. In our case:

template <typename T>
class my_class {
public:
    explicit my_class(T val) : m_val(val) {}
    void print_val() const { std::cout << m_val << std::endl; }
    [[nodiscard]] T get() const { return m_val; }
    void set(T val) { m_val = val; }

    T m_val;
};

// Integer specialization
template<>
class my_class<int> {
public:
    explicit my_class(int val) : m_val(val) {}
    void print_val() const { std::cout << m\_val << std::endl; }
    [[nodiscard]] int get() const { return m_val; }
    void set(int val) { m_val = val; }

    int m_val;
};

// Double specialization
template<>
class my_class<double> {
public:
    explicit my_class(double val) : m_val(val) {}
    void print_val() const { std::cout << m_val << std::endl; }
    [[nodiscard]] double get() const { return m_val; }
    void set(double val) { m_val = val; }

    double m_val;
};

This way the compiler can make the decision which my_class specialization you refer to in your code.

Class Specializations Deduction

Since the class’s CTOR signature is different for every specialization, you don’t have to explicitly mention the class type:

int main() {
    my_class mc_i(5); // Integer specialization
    my_class mc_l(5l); // Long specialization
    my_class mc_d(5.0); // Double specialization
    my_class mc_f(5.f); // Float specialization

    return EXIT_SUCCESS;
}

However, to use a CTOR that doesn’t have a unique signature for an specialization, you’ll still have to explicitly mention the type:

// my_class::my_class() {}

int main() {
    // my_class mc_i; // Deduction failure: "No viable constructor or deduction guide for deduction of template arguments of 'my_class'"
    my_class<int> mc_i; // Integer specialization

    return EXIT_SUCCESS;}

Conclusion

This is all for the first part of basic templates usage. You are more than welcome to share your thoughts about templates and the instantiations. Personally, it took me long time to agree with the way the compiler copy the class for every different type of usage, back in the days it just seemed to me like a huge waste of code memory. Today I think it’s better than slow down performances in order to deduce the types at run time.

This post originally published on my personal blog: C++ Senioreas.

C++ Meta Programming: Why?

Coral Kashri — Sat, 25 Jul 2020 09:21:27 +0000

As the time goes by, C++ meta programming features keep increase and improve. Every release adds more and more meta programming features, although you can write a complete program without using it even once. So why does this topic draw so much attention, and why does it considered as one of the most powerful tools of C++?

This article is the first in a series of articles about meta programming in C++. The examples in this article are just for demonstration of the abilities of metaprogramming in C++, and some of them won't get explain here, but in future articles.

Next post on series: Basic templates usage – Part 1

Meta Programming VS. Generic Programming

Most of the high-level programmers, who go lower into C++, usually refer to C++ templates as "Generic Programming", because in high level languages like Java or C#, the expression <T> means a generic parameter. In C++, calling templates "Generic Programming" simply means underestimation of templates. This topic is far bigger, more complex, and full of possibilities to just call it "Generic".

Let’s start with a simple example of templates:

template <typename T>
class Foo {
public:
    explicit Foo(T val) : val(val) {}
    T val;
};

So far it doesn’t look so much more than a “Generic” class. We can call it like this:

Foo<int> f(5);

Or like this:

Foo f(5);

Wait, Can we just throw away the template specification? Sometimes the answer for this question is Yes. This feature called template argument deduction, and on the basic level, it means that whenever the compiler can deduce the types at the compilation time, it will, in order to save you a hard-coding time, or to avoid complex code, as much as possible (don't worry, it won't stay that easy for much longer).

Let’s take this Foo class one step forward:

void foo_func(std::string s) {
    std::cout << "Foo Func: " << s << std::endl; // Think about this line for a moment... Can you see the deduction here? Even in the first "Hello World" program in C++ we are using template parameters deduction.
}

// ... main ...

Foo f2(foo_func);
f2.val("A");

No, it's still the same Foo class from before, no change at all, the deduction here is: void(*)(std::string) - a function pointer. But, deduction isn't enough to convince anyone to stop calling C++ templates as "Generic Programming", so take a deep breath, we are going deeper.

Compile time values calculation

Meta programming become the run-times ultimate saver - anything we can compute at the compilation time, we'll do it there, and with the most readable way we can.

const my_highly_important_value = 4194304;

Some of you might guess it's not a random value and might even recognize it as the exact result of 2 ^ 22. Yes, I could add a comment or give it a more informative name, but I could also do something like that:

// some math library
template <size_t Base, size_t N>
struct pow {
    static constexpr long long val = Base * pow<Base, N - 1>::val;
};

template <size_t Base>
struct pow<Base, 0> {
    static constexpr long long val = 1;
};

// ...

const my_highly_important_value = math::pow<2, 22>;

For the full explanation & example about how this works there will be a future post, a simple explanation for now: A recursion on compile time to compute the desire value. About the run time, there is no different at all between const my_highly_important_value = 4194304; and const my_highly_important_value = math::pow<2, 22>; but we can clearly see which one is better.

Explicit template functions specialization

Another possibility that gave us the meta programming is the explicit (full) template functions specializations. Assume you have a function that accepts a single template parameter. Your function knows how to deal with any numeric type, but you have a special implementation for floats. You know a way to make this function run faster if it get to handle floats, but you still don't want to eliminate the rest of the types implementation. Two ways to handle this situation:

Create a different function with a different name for floats.
Use explicit template specialization/constexper conditions for float cases.

If you had decided to be nicer to your team, you would have probably chosen the second option (but I don't judge for choosing the easy way, it's still legal to make mistakes). Since C++17, you can use constexpr conditions:

template <typename T>
void function(T type) {
    if constexpr (std::is_same_v<T, float>) {
        std::cout << type << " is float!" << std::endl;
    } else {
        std::cout << type << " is not a float!" << std::endl; 
    }
}

And once again - the condition is on compilation time, no extended run time needed.

And Much More…

All these features and we didn't talk about template inheritances, variadic templates, template conditions (extended version of the last example), constexpr functions, auto, and more...

Conclusion

There are much more in templates than a "Generic Programming" especially since C++17/20, and we'll talk about it in future posts in this series. Please comment if you have specific subjects you'd like to see in the future posts and describe your experience with meta programming.

This post originally published on my personal blog: C++ Senioreas.