DEV Community: Michał Piotrowski

From Java to C++ - lambdas

Michał Piotrowski — Fri, 26 Nov 2021 11:08:48 +0000

In Java, we have our take on functional programming with lambdas. Obviously, as functional programmers love to tell us - they're just a mere simplifications of the 'real' functional languages. However, introduced in Java 8, they've had really changed how we do things in Java now. As for C/C++, functions were there from the very beginning (obviously!), but concepts of lambdas emerged just in the latest C++20 standard.

In this post I will try to take more broad approach to the concepts of functions and lambdas in C++. I've thought about writing about C function pointers, but I've decided to just refresh my memory with Richard Reese Understanding and using C pointers' book, but do not write about it here. Let's keep it pure C++, and concentrate on more abstract solutions. Like the one just coming in our way - functions as objects.

Function as an object

The concept of functions being first class citizens in the programming languages has a long tradition. In order to achieve that in C++, we need a way to pass functions to the methods as params. A universal container for callable objects is std::function class - wrapper around function pointer. It's a piece of standard library, residing in the header. I'm starting with it, as it is more generic than lambdas.

In general, it's possible to create an empty std::function object, but that won't be much of use - trying to call such object will result in std::bad_function_call exception being thrown. What we need, is object that actually holds a callable 'thing'. There are two ways to assign a callable object to the std::function instance - either as a constructor param, or just by assigning it to the pointer. Here's an example:

#include <iostream>
#include <functional>

void testFunction()
{
    std::cout << "Test function";
}

int main()
{
    std::function<void()> testFunctionHandler { testFunction };
    std::function<void()> testFunctionHandler2 = testFunction;

    testFunctionHandler();
    testFunctionHandler2();
}

It does not look scary - maybe syntax is a little weird, but nothing we cannot handle. std::function can serve as w convenient abstraction, representing all the types of callable things. However, here's the more modern approach to functional programming in C++ (and more close to Java equivalent) - lambdas.

Lambdas in C++

The same as in Java, it's a popular use case, to just pass some behaviour represented by a function. We don't need to (or don't want to), create a separate function or an object for that. What we want, is to pass some behaviour to the method and let it do its job. That's what lambdas are for - simple (ok, got me) concepts of passable behaviour. Let's start with the most simple example of a function - that takes nothing and returns nothing (besides side-effect):

#include <iostream>

void printSomeMsg() {
    std::cout << "Some message" << std::endl;
}

int main() {
    printSomeMsg();
}

As simple as it is - it just prints the hardcoded message. However, let's assume that we don't want to write such a trivial function in our code. We just need its functionality in the specific places. That's where the lambda comes in. Let's take a look at this:

#include <functional>
#include <iostream>

int main() {
    auto ourLambdaAsAuto = []() { std::cout << "Some message" << std::endl; };
    std::function<void()> ourLambdaAsFunction = []() { std::cout << "Some message 2" << std::endl; };

    ourLambdaAsAuto();
    ourLambdaAsFunction();
}

Again, the syntax may look scary at the beginning, but that's not that big of a deal. Let's go through it step by step:

[] - it is empty now, but that does not mean it's not being used. These square brackets are responsible for specifying captures. In simple words - they fetch needed data/variables from the calling context. We will discuss this in detail later, as it is quite important.
() - rather familiar feature. In the simple parenthesis we just specify arguments to the lambda. We don't have any here, that's why it's empty.
{} - in the curly braces we provide the body of our lambda. In short - the job to be done.

Wasn't that bad, right? Of course, our simple example did not cover everything. Generic expression for lambda creation looks like this:

[captures] (parameters) modifiers -> return-type { body }

From the above expression we know already captures, parameters and body. The remaining two are quite simple:

modifiers - we can specify different modifiers, but depending on the standard they may vary, and their behaviour too. The best way to learn about them is to visit official C++ ref docs. The most popular are const and constexpr.
return type - by default the compiler will deduce the return type of the lambda. However, especially when we're using template lambdas, it's advisable to help the compiler with small hint. Like in this example: [](auto x, double y) -> decltype(x+y) { return x + y; }

More about lambdas params

Parameters to lambdas are not that different from the regular ones. That means, we can both assign to them default values, and use auto type. Slightly modified example taken from 'C++ Crash Course' shows these two in combination.

#include <iostream>

int main() {
    auto increment = [](auto x, int y = 1) { return x + y; };
    std::cout << increment(10) << std::endl;
    std::cout << increment(10, 5) << std::endl;
}

Lambda captures

Remember these square brackets that up until now we've always left empty? Now the time has come to tell something more about them. Captures are quite important for lambdas, as they allow them to have context passed. Let's start with simple example.

#include <iostream>

class MySimpleClassPiece {
    public:
        int x;
        std::string someStringValue;
};


class MySimpleClass {
    public:
        MySimpleClassPiece piece;
};



int main() {
    MySimpleClass mySimpleClass { MySimpleClassPiece {1, "someStringValue"} };

    std::cout << mySimpleClass.piece.someStringValue << std::endl;
    std::cout << mySimpleClass.piece.x << std::endl;
}

Everything here is public, for the sake of simplicity. Printing to the standard output is done directly in the main function, and that is not what we want in the long run. Let's assume, that based on some logic, we want to either print the object state to the console, or modify the values in the object. As this is purely behaviour-driven thing, we're going to use lambdas for this. Let's start with the printing piece first.

// Everything besides main() is the same as above
int main() {
    MySimpleClass mySimpleClass { MySimpleClassPiece {1, "someStringValue"} };
    auto printingLambda = [mySimpleClass]() {
        std::cout << mySimpleClass.piece.someStringValue << std::endl;
        std::cout << mySimpleClass.piece.x << std::endl;
    };
    printingLambda(); 
}

Running above code snippet produces the same output as before. What happened here? In general, in the capture section of a lambda, we can put whatever parameters we want, and what is more, we can select variables from the calling context, to pass into the lambdas' body (as presented above). By default, all the variables are passed by value!

Of course, we're not limited to just passing the value - we can change its name. It is done like this:

int main() {
    MySimpleClass mySimpleClass { MySimpleClassPiece {1, "someStringvalue"} };
    auto printingLambda = [externalVariable=mySimpleClass]() {
        std::cout << externalVariable.piece.someStringValue << std::endl;
        std::cout << externalVariable.piece.x << std::endl;
    };
    printingLambda();
}

Using this technique can improve the readability of the code, especially when the lambda is contained within the same compilation unit. But that's not over! When it comes to parameters, we can also provide new ones, completely unrelated to the context variables.

int main() {
    MySimpleClass mySimpleClass { MySimpleClassPiece {1, "someStringvalue"} };
    int xx = 5;
    int zz = 10;

    auto printingLambda = [externalVariable=mySimpleClass, y = 1, z = 5, result = xx + zz]() {
        std::cout << externalVariable.piece.someStringValue << std::endl;
        std::cout << externalVariable.piece.x << std::endl;
        std::cout << y + z << std::endl;
        std::cout << result << std::endl;
    };
    printingLambda();
}

This piece of code will actually print:

someStringvalue
1
6
15

As you can see this feature is quite powerful, and enables lambda to get as much data as needed, to perform a specific operation. However, up until now we're operating with named parameters - we're specifying all of them in the captures section. That gives us a lot of flexibility, but sometimes we just want to pass everything to the lambda at once. We don't want to provide variables one by one, or (in the future), have to add additional params when new variables appear.

The way to achieve that, is to use 'wildcard-style' in the square brackets. By putting there '=' sign, we pass to the lambda all the variables that enclosing context contains, and lambda wants to use. As simple as that:

int main() {
    MySimpleClass mySimpleClass { MySimpleClassPiece {1, "someStringvalue"} };
    int xx = 5;
    int zz = 10;
    int result = xx + zz;

    auto printingLambda = [=]() {
        // Pay attention that we have to use the name of the original variable here! 
        std::cout << mySimpleClass.piece.someStringValue << std::endl;
        std::cout << mySimpleClass.piece.x << std::endl;
        std::cout << result << std::endl;
    };
    printingLambda();
}

It makes the code easier to maintain, but as I've said - it may influence the readability. Therefore, it's always situation based, whether we use default capture or named one. Ok, so far we've been dealing with parameters' values, as by default the parameters are passed by values. What if the lambda wanted to actually modify them? Trying to do that in the above example will fail.

auto printingLambda = [=]() {
    std::cout << mySimpleClass.piece.someStringValue <<; std::endl;
    std::cout << mySimpleClass.piece.x << std::endl;
    std::cout << result << std::endl;
    result = 14;   // Results in compilation error with:  assignment of read-only variable 'result'
};

If we want to make modifications to the variables, we could fall in a nasty trap here. I've mentioned in the list above, that one part of lambda expression can belong to modifiers. One of them is actually mutable. Sounds about right! Let's take a look at the following code, and try to predict how it behaves.

int main() {
    int toAdd = 0;

    auto printingLambda = [=]() mutable {   //  mutable added 
        toAdd += 5;
        std::cout << toAdd << std::endl;
    };

    printingLambda();
    std::cout << "In main: " << toAdd << std::endl;
    printingLambda();
    std::cout << "In main: " << toAdd << std::endl;
    printingLambda();
    std::cout << "In main: " << toAdd << std::endl;
}

If you've expected ever-increasing output I have bad news for you. It actually looks like this:

5
In main: 0
10
In main: 0
15
In main: 0

Weird, isn't it? The problem here is, that mutable does not allow modifying params passed by values - quite reasonable I would say. What it does instead, is that it creates a new variable named exactly as the one used (in this example it is toAdd), and then keeps it in memory, as long as lambda is in use. That explains how we got this specific output.

All right, but what if I want to modify actual variables from the outside world. Well, that's not a problem - just pass them as references. We can do that by replacing '=' sign with '&' one.

int main() {
    int toAdd = 0;

    auto printingLambda = [&amp;]() {
        toAdd += 5;
        std::cout << toAdd << std::endl;
    };

    printingLambda();
    std::cout << "In main: " << toAdd << std::endl;
    printingLambda();
    std::cout << "In main: " << toAdd << std::endl;
    printingLambda();
    std::cout << "In main: " << toAdd << std::endl;
}

With that change, our output looks like we wanted it for the first time:

5
In main: 5
10
In main: 10
15
In main: 15

What must be said here, is that we're not limited to either named captures and default ones! We can mix them for every lambda! Here's an example:


int main() {
    int toAdd = 0;
    int x = 5;

    auto printingLambda = [=, &amp;toAdd]() {
        toAdd += 5;
        std::cout << toAdd << std::endl;  // toAdd passing/changes will work as in the previous example

        std::cout << x << std::endl;
        // x += 10;   This line will cause compiler to fail
    };

    // printing skipped
}

To finish discussing captures I have to mention, that it's also possible to pass to the lambda (either by value or by reference), an actual instance of the wrapping class. However, the topic is not trivial - I recommend reading an excellent article on Nextptr.com. What is more - linked presentation in the sources section also provides valuable info about it. That's it for today.

SOURCES:

Free ebook about lambdas - whole book dedicated to lambdas in C++. Just provide email address and it's yours.
Introduction to lambdas - BackToBasis series on CPPConf
'Understanding and using C Pointers' by Richard Reese, chapter about function pointers
'C++ Crash Course' by Josh Lospinoso
Nexptr.com article about the evolution of this capturing

From Java to C++ - inheritance

Michał Piotrowski — Tue, 23 Nov 2021 18:35:40 +0000

This post will be short, however I think it could be useful for people, especially the ones coming from Java to C++. Today I want to cover inheritance, which may seem like a trivial thing, but actually it's not. Maybe not at its core - every Java developer will be able to understand it in C++. I would like to concentrate more on the semantics of it.

Scope first

Let's start with scopes in C++, as this is an easy one. We have only three scopes in C++, which are known to us already (coming from Java) - public, protected and private. No surprises there at all. Public means public (visible to everyone), protected is protected - only children of specific class have access to such members. At the end there's private modifier - members accessible only from within the class. So far everything clear.

The problem arises when it comes to writing things down in the code. In Java, we're used not only, to have access modifiers in the front of the class, but also to specify them for every method (I omit default public modifier in interfaces, let's not get distracted). In C++, we actually group class members in the scope sections which look like this:

class MyClass 
{
    public:
        int someMethod();

    protected:
        int someOtherMethod();

    private:
        int x, y;
}

Their order does not matter, and what is more - there can be a couple of them! Below class will work just fine:

class MyClass
{
    public:
        int someMethod();

    protected:
        int someOtherMethod();

    private:
        int x, y;

    public:
        int someMethod2();

    private:
        int z;
}

Looking weird, right? To be honest - I did not reach 'C++ style guide' yet, but I expect that there's a tip to use only single scope sections in a class. Ok, let's move on.

Inheritance

Scope inheritance

When we're inheriting from one class, we have to use : operator to indicate that. At the same place, we can specify one of the access modifiers, that will decide, what are the child class members' visibility. The base construction looks like this:

class Parent {};
class Child : ACCESS-MODIFIER Parent {};

In the place of ACCESS-MODIFIER we can put one of the already known modifiers - public, protected or private. When the modifier is not specified, it defaults to private! Based on the used modifier, inherited class members have the following access modifiers:

Public
- public remain public
- protected remain protected
- private remain private
Protected
- public becomes protected
- protected remain protected
- private remain private
Private
- public become private
- protected become private
- private remain private

Methods inheritance

As C++ is OO-language, obviously there must be also inheritance of methods' behaviour, right?. However, it also works differently than in Java. Let's see an example:

class Parent {
    public void someMethod() {
        System.out.println("Parent");
    }
}

class Child extends Parent {
    public void someMethod() {
        System.out.println("Child");
    }
}

public static void main(String []args) {
    Parent p = new Parent();
    Child c = new Child();
    Parent referenceToChildUsingParent = c;

    p.someMethod();
    c.someMethod();
    referenceToChildUsingParent.someMethod();
}

Code is as simple as possible. If there's a method in the parent class, and we don't limit its scope in the child, there's no problem with inheriting it, and overriding. Output would be:

Parent
Child
Child

With C++ it's not the same. An equivalent of the above Java code should look like this:

#include<iostream>

class Parent {
    public:
        void say() {
            std::cout << "Parent says hi!" << "\n";
        }
};

class Child : public Parent {
    public:
        void say() {
            std::cout << "Child says hi!" << "\n";
        }
};

int main()
{
    Parent parent;
    Child child;
    Parent& referenceToChildUsingParent = child;

    parent.say();
    child.say();
    referenceToChildUsingParent.say();
}

Can you guess the output? Here it is:

Parent says hi!
Child says hi!
Parent says hi!    // Yes, that's not a mistake!

By default, when no other modifiers are specified, type of the reference 'wins'. In order to achieve the same result as in Java, we have to tell the compiler that we want to use a derived class method implementation when it is present. Here's the code:

#include<iostream>

class Parent {
    public:
        virtual void say() {   // Notice the usage of VIRTUAL here
            std::cout << "Parent says hi!" << "\n";
        }
};

class Child : public Parent {
    public:
        void say() {
            std::cout << "Child says hi!" << "\n";
        }
};

int main()
{
    Parent parent;
    Child child;
    Parent& referenceToChildUsingParent = child;

    parent.say();
    child.say();
    referenceToChildUsingParent.say();
}

The output now is the same. Virtual acts similar to default modifier in Java - there's a present implementation of method in the parent, and it's used by default. However, if a method is overridden in the child class, it is being used. Usage of virtual can be strengthened with usage of override keyword in the children classes. They act like @override annotation in Java - indicating the fact, that the method is inherited. When we use override, and there's no matching method signature in the parent class, a compiler will fail.

class Parent {};

class Child : public Parent {
    public:
        void say() override {    // This line will cause compilation error
            std::cout << "Child says hi!" << "\n";
        }
};

In Java, in addition to default keyword (introduced in Java 8, and applying only to interfaces), we have good old abstract modifier. As a reminder - classes/methods declared as abstract, cannot be instantiated. The same applies in C++, although the syntax is different. What is more, we call these types of methods (requiring concrete implementations in children) - pure virtual methods/functions. Let's take a look:

#include<iostream>

class Parent {
    public:
        virtual void say() =0;   // =0 is an equivalent of 'abstract'
};

class Child : public Parent {
    public:
        void say() override {
            std::cout << "Child says hi!" << "\n";
        }
};

int main()
{
    //    Parent parent;   This line will cause compilation error when uncommented
    Child child;
    Parent& referenceToChildUsingParent = child;

    child.say();
    referenceToChildUsingParent.say();
}

Using this syntax, it's possible to actually achieve interface functionality in C++, although there's no such concept in it (supported by the language as in Java). Just declare all the class methods as pure ones, and it's a state-of-art interface at hand. Here one important thing should be mentioned - it's a good practice, which can prevent resources from leaking - always implement virtual destructor in the base class/interface!. It's enough to use




keyword for that - indicating that we let compiler generate the body of this method automatically.



```cpp
class Parent {
public:
    virtual void say() =0;
    virtual ~Parent() =default;
};

Ok, where's my class access modifier?

Well, actually, there's none. That's right. There's no concept of the class access modifier. Everything is decided on the class
members level, and there's nothing that we can do about it. Coming from Java world it seems like a huge limitation. However, concept of C++ modules, which was introduced in C++20, seems to help here, but I don't want to dive into it yet. I have plans to write a separate post about it in the future.

Friend functions

'Speak friend, and enter' comes right to mind, right? Again - I was surprised to discover this concept in C++. It's something-almost-like package-private modifier in Java, although that's not exactly it. In short - friend functions are able to actually access private and protected elements of the class, while not being their members. Wat? Yup, you read it right. Below code should shed some light on the concept, although this functionality is way more complicated than below example (taken from official CPP reference).

class Y {
    int data; // private member
    // the non-member function operator<< will have access to Y's private members
    friend std::ostream& operator<<(std::ostream& out, const Y& o);
    friend char* X::foo(int); // members of other classes can be friends too
    friend X::X(char), X::~X(); // constructors and destructors can be friends
};

// friend declaration does not declare a member function
// this operator<< still needs to be defined, as a non-member
std::ostream& operator<<(std::ostream& out, const Y& y)
{
    return out << y.data; // can access private member Y::data
}

SOURCES:

Josh Lospinoso 'C++ Crash Course' book
CPP reference about friend functions and objects
SO question when you should use friend functions

From Java to C++ - copy&move semantics

Michał Piotrowski — Fri, 05 Nov 2021 12:46:08 +0000

WARNING!!!WARNING!!!WARNING!!!

After consulting with my C++ coach, this article was rewritten almost from scratch. I'm leaving it here for the documentation purposes, but please do not base your learning on it. Visit my blog for the most recent and valid version - link.
WARNING!!!WARNING!!!WARNING!!!

In my opinion, in Java we do not care that much about object creation and then assigning them to other variables. In general, due to GC inner-workings, we're more reluctant in this area, than C++ programmers. However, that's not the only reason why I've decided to write this post. Recently a survey result appeared in my social feed claiming, that move semantics and understanding object lifecycle is not a piece of cake. In order to cover all my bases, I've decided to dive into the topic a little deeper. Here we go.

DISCLAIMER! Obviously I'm not an experienced C++ programmer, therefore there's always a possibility, that my knowledge is not enough. I've put a lot of effort, to write this article and make it as good as possible. However, if you think that some concepts or explanations are wrong, please, don't hesitate to point them out!

Copy semantics

I'm mentioning copy semantics here, mostly for the sake of completeness, and to introduce some working code example. In fact, it works exactly the same in Java. Every time we assign an already existing object to the new one (or even existing one), a shallow copy is performed. Below code snippet in Java:

class MyObject {
  int i = 5;
  String s = "test";
}


MyObject obj1 = new MyObject();
MyObject obj2 = obj1;

obj1.i = 9;

System.out.println("Obj1: " + obj1.i);
System.out.println("Obj2: " + obj2.i);

Will print:

Obj1: 9
Obj2: 9

For the C++ equivalent we can use this code:

#include <iostream>

using namespace std;

class MyObject {
public:
    MyObject()
    {
        i = 5;
        myString[0] = 'a';
    }

    void setMyString(char newString)
    {
        myString[0] = newString;
    }
    char getMyString()
    {
        return myString[0];
    }
private:
    int i;
    char* myString = new char[1];   // size is hardcoded, but we don't care here
};

int main()
{
    MyObject obj1;
    MyObject obj2 = obj1;

    cout << "Obj1: " << obj1.getMyString() << endl;
    cout << "Obj2: " << obj2.getMyString() << endl;

    obj1.setMyString('b');

    cout << "Obj1: " << obj1.getMyString() << endl;
    cout << "Obj2: " << obj2.getMyString() << endl;

    return 0;
}

Passing objects as params - copy it is

In works in the same way with C++, also when an object is passed to the function/method. As long as we don't operate on references or pointers, a shallow copy of the passed object is created, and passed as na argument. Take a look at the following code:

#include <iostream>

using namespace std;


class MyObject {
public:
    MyObject()
    {
        i = 5;
        myString[0] = 'a';
    }

    void setMyString(char newString)
    {
        myString[0] = newString;
    }
    char getMyString() const
    {
        return myString[0];
    }
    void setI(int newI)
    {
        i = newI;
    }
    int getI() const
    {
        return i;
    }
private:
    int i;
    char* myString = new char[1];   // size is hardcoded, but we don't care here
};


void doSthWithObject(MyObject myObject)
{
    myObject.setI(9);
}

int main()
{
    MyObject obj1;
    MyObject obj2 = obj1;

    cout << "Obj1: " << obj1.getMyString() << endl;
    cout << "Obj2: " << obj2.getMyString() << endl;

    doSthWithObject(obj1);

    cout << "Obj1: " << obj1.getI() << endl;
    cout << "Obj2: " << obj2.getI() << endl;


    obj1.setMyString('b');

    cout << "Obj1: " << obj1.getMyString() << endl;
    cout << "Obj2: " << obj2.getMyString() << endl;

    return 0;
}

Which produces this output:

Obj1: a
Obj2: a
Obj1: 5
Obj2: 5
Obj1: b
Obj2: b

Constructor for one?

So far we saw nothing new. In exactly the same way works a custom constructor (called copy constructor), that takes an object as a parameter. It's up to the programmer how this constructor will create a new object - it can be either simple shallow copy, or even a deep copy:

class MyObject {
public:
    MyObject()
    {
        i = 5;
        myString[0] = 'a';
    }

    MyObject(MyObject& obj)
    {
        i = obj.getI();           // shallow copy as it is a primitive/internal object
        myString = new char[1];   // dynamic allocation of memory
        strncpy(myString, new char[1]{obj.getMyString()}, 1);   // copying the VALUE of the object, not the reference
    }

    // set/get methods omitted
private:
    int i;
    char* myString = new char[1];   // size is hardcoded, but we don't care here
};

int main()
{
    MyObject obj1;
    MyObject obj2 = obj1;

    cout << "Obj1: " << obj1.getMyString() << endl;
    cout << "Obj2: " << obj2.getMyString() << endl;

    MyObject obj3 {obj1};    // Usage of COPY CONSTRUCTOR
    cout << "Obj1: " << obj1.getI() << endl;
    cout << "Obj3: " << obj3.getI() << endl;

    obj1.setMyString('b');

    cout << "Obj1: " << obj1.getMyString() << endl;
    cout << "Obj3: " << obj3.getMyString() << endl;

    return 0;
}

Which produces this output:

Obj1: a
Obj2: a
Obj1: 5
Obj3: 5
Obj1: b    
Obj3: a   // Value is unaffected

Gimme some equal copy!

You may say - again - nothing new under the sun. Been there, done that. However, C++ has some more magic to offer than Java. In general, it is possible in C++ to override not only the class methods, but also operators used on it! That's something you can't see in Java (maybe I should add - yet). Overriding an operator is simple - technically it's like overriding a method. However! With a great power, comes great responsibility! Let's see how it may go wrong.

int main()
{
    MyObject obj1;
    MyObject obj2 = obj1;

    cout << "Obj1: " << obj1.getMyString() << endl;
    cout << "Obj2: " << obj2.getMyString() << endl;
    cout << "-----" << endl;

    MyObject obj3;               // New object created
    obj3.setMyString('b');       // New value assigned to the string

    obj3 = obj1;   // Here is the main part!!

    cout << "Obj1: " << obj1.getMyString() << endl;
    cout << "Obj2: " << obj2.getMyString() << endl;
    cout << "Obj3: " << obj3.getMyString() << endl;

    return 0;
}

The output is as predicted:

Obj1: a
Obj2: a
-----
Obj1: a
Obj2: a
Obj3: a

The question is - what happens under the hood? In our situation, every new object has its own instance (and therefore dynamically allocated memory) of myString. With the default behaviour of the copy assignment, we're making only a shallow copy of the string instance when assigning
obj1 to obj3! The memory allocated for the string instance in the obj3 leaked! That's something we have to pay attention to, when (re)assigning objects around! In Java, GC process will take care of the lost memory, in C++ - no way.

So how do we fix this? General rule of thumb is that we need to override the assignment operator, and before we make all the assignments of data, we have to make sure, that we free all the memory we've allocated in the object. The solution in our example should look like this:

MyObject& operator=(const MyObject& objToCopyFrom)
{
    if( this == &objToCopyFrom) return *this;         // that prevents unnecessary work if the same instance is passed
    delete[] myString;                                // we free the memory allocated for the array
    myString = new char[1]{objToCopyFrom.getMyString};  // Just use passed object value
    i = objToCopyFrom.getI();            // Same with int - but it's internal type, so no need to think about memory
    return *this;                        // Just return current instance
}

So what's the default behaviour?

In general, the logic standing behind automatic generation of copy operator and copy constructor is quite robust, and caution is advised while using them. Two objects after copying should not alter their states (as we saw above), and also should not leave any of the objects in the inconsistent state. To finish this topic it is worth mentioning, that there's a possibility to explicitly indicate, that we're fine (or not) with default implementations generated by the compiler. Here are the examples:

MyObject(const MyObject&) = default;    // Yes, I'm happy with default implementation
MyObject(const MyObject&) = delete;     // I'm not happy with defaults - remove the auto-generation and raise 
compiler error when such situation occurs

Move semantics

With the previous chapter we've introduced a foundation for explaining more advanced concept, which is move semantics. To start with (and I was surprised to learn that), move semantics wasn't present in C++ before C++11! So pay attention to that fact. Second thing that we have to start with, is the difference between lvalue and rvalue

Lvalue vs Rvalue

Here, I would use a direct quote from 'C++ Crash Course':

We'll consider a very simplified view of value categories. For now, you'll just need a general understanding of
lvalues and rvalues. An lvalue is any value that has a name, and
an rvalue is anything that isn't an lvalue.

To make it easier - here are the usual things that are rvalues - temporary objects, literal constants, function return values (unless they're lvalues passed as params) and usually results of built-in operators.

I know that it might sound like explaining the unknown through unknown, however, I think that simple code example (taken from the same book) would explain the concept:

#include <cstdio>

void ref_type(int &x) {
    printf("lvalue reference %d\n", x);
}

void ref_type(int &&x) {
    printf("rvalue reference %d\n", x);
}

int main() {
    auto x = 1;
    ref_type(x);
    ref_type(2);
    ref_type(x + 2);
}

The output is:

lvalue reference 1
rvalue reference 2
rvalue reference 3

The idea behind move semantics

Why this concept is important? Let's go back to the example used in the previous subchapter. Our code there, had an array of chars inside. Imagine for a moment, that this array holds a large amount of chars, like millions or so. Copying all this data back and forth would be a tremendous waste of both - memory and time. What is more, quite often, when we assign an object to the new reference (or we pass it as a constructor parameter), we actually don't care about the source object anymore. We just need new reference to hold the data, and underlying memory does not bother us, as we want to discard the source object. That's the perfect situation when move semantics can be used.

Enough talk, show me the code. Let's revisit an example already shown above.

#include <iostream>

using namespace std;

class MyObject {
public:
    MyObject()
    {
        i = 5;
        myString[0] = 'a';
    }

    void setMyString(char newString)
    {
        myString[0] = newString;
    }
    char getMyString()
    {
        return myString[0];
    }
private:
    int i;
    char* myString = new char[1];   // size is hardcoded, but we don't care here
};

int main()
{
    MyObject obj1;
    MyObject obj2 = obj1;

    cout << "Obj1: " << obj1.getMyString() << endl;
    cout << "Obj2: " << obj2.getMyString() << endl;

    obj1.setMyString('b');

    cout << "Obj1: " << obj1.getMyString() << endl;
    cout << "Obj2: " << obj2.getMyString() << endl;

    return 0;
}

The problem we had before was, that after we've assigned obj1 to obj2, we wanted to use both of them later. Or more precisely, we wanted to use the objects that were referenced by obj1 and obj2. As I've mentioned above, quite often we don't need that. We just want to perform a copy of one object (so we're interested in its values), but we don't care that much about the remaining reference. There are two ways to achieve that, similarly to the copying above - through move constructor or move assignment. What's the difference between them, and their copying counterparts? Just one - usage of rvalues. As usual - code speaks thousands words.

// I present only the new methods, fields of the class are public for readability
MyObject(MyObject&& obj) noexcept  // Here's the change
{
    i = obj.i;
    myString = new char[1]{*obj.myString};
    // Below we 'empty' the source object.
    obj.i = 0;
    obj.myString = nullptr;
}

MyObject& operator=(MyObject&& objToCopyFrom) noexcept   // Here's the change - RVALUE present as a param
{
    if( this == &objToCopyFrom) return *this;   // that prevents unnecessary work if the same instance is passed
    delete[] myString;                          // we free the memory allocated for the array
    myString = new char[1]{*objToCopyFrom.myString};
    i = objToCopyFrom.i;

    // Below we 'empty' the source object.
    objToCopyFrom.i = 0;
    objToCopyFrom.myString = nullptr;

    return *this;
}

We have a couple of changes here that we need to look at.

noexcept - in general we don't expect these methods to throw any kind of exceptions. We cannibalize the source object, and all the operations are either simple copies of values or reassignment of memory addresses.
no const - pay attention to that! As we're 'emptying' the source object, we must be able to actually change its state. Therefore we cannot use const in the parameters.
emptying source object - already mentioned this one. In general, we leave the source object 'in statu nascendi', which means it is raw/virgin state. There's no problem with reusing existing reference to assign a new object to it, however the reference itself at this time is 'empty'.

The last point above can be a source of the problems. The programmer must always remember to clean up the source object, in order to avoid nasty runtime errors (like double-free ones). Therefore, when possible, try to reuse existing move constructors/operators, or use

cpp std::exchange

function, that performs move operation, but also nulls the source object. Here's the code:

// This thing
myString = new char[1]{*objToCopyFrom.myString};
objToCopyFrom.myString = nullptr;

// Can be done like this
myString = std::exchange(*objToCopyFrom.myString, nullptr);

Ok, but how I get rvalue?

That's the valid point. In general, if we create a new object, and at the same time we pass it to the constructor (or assign it) we should be fine. However, the examples above were showing assigning already existing object/reference (so - lvalue). To help us with move semantics C++ introduced a function in the STD called move (its definition can be found in header). Its purpose is to cast any lvalue to rvalue, and therefore to use existing references in the move semantics.

An example from 'C++ Crash Course':

#include <cstdio>
#include <utility>

void ref_type(int &x) {
    printf("lvalue reference %d\n", x);
}

void ref_type(int &&x) {
    printf("rvalue reference %d\n", x);
}

int main() {
    auto x = 1;
    ref_type(std::move(x));
    ref_type(2);
    ref_type(x + 2);
}

The output is:

rvalue reference 1
rvalue reference 2
rvalue reference 3

Summary

Copy and move semantics are crucial to understand, in order to properly interact with objects, and understand their lifecycle. Failing to do so, can result in nasty runtime bugs and possible memory leaks. This topic has its own section in the core guidelines, that author of the language - Bjarne Stroustrup - created and published for everyone to benefit from. So please, take a look at them too.

SOURCES:

Josh Lospinoso 'C++ Crash Course' book
Back to basics - Move semantics - CPPCon 2020
Hidden secrets of - move semantics - CPPCon 2020
Klaus Iglberger Back to Basics: Move Semantics part one and part two from CppCon 2019

From Java to C++ - templates

Michał Piotrowski — Thu, 14 Oct 2021 18:28:25 +0000

Generic programming is everyday bread for possibly every Java programmer out there. Only the oldest Java programmers out there still remember the times, when we're casting things all over, and lists were instantiated without explicitly telling the compiler what type of objects they hold. There should be no surprise that the same functionality exists in Java's older cousin - C++.

DISCLAIMER 2! I didn't want to go with full-blown history lesson here. I'm using the latest C++20 standard and all the examples are compiling and working in it. I may indicate once in a while when specific functionality was introduced.

Let's go

Generic programming in the C++ is strictly related to the concept of a template. Although, in the Java world we're used to the idea of generics, templates in C++ are a little different, and in my opinion, harder to grasp. In this article, I will try my best, to present generic programming in C++ in a way, that every Java programmer should easily understand. Let's start with a definition of template, given by Stroustrup himself.

Basically, a template is a mechanism that allows a programmer to use types as parameters for a class or a function. The compiler then generates a specific class or function when we later provide specific types asarguments.

We can select three separate types of templates:

function templates
class templates
variable templates (since C++14)

Additional typology comes with the template parameters
evaluated during compile time), in other words, what can be passed as a parameter to the template keyword:

param types - the most common ones, eg.

template<typename|class T>
none-type parameters - usually already provided value, eg. number 6. Since C++20 it's also possible to use floating-point numbers and C-style strings (arrays), although with some limitations. However, a lot of other types can be used here as enums, pointers of all kinds or std::nullptr_t
template-template parameters - when we inject a template into another template

Here we must remember, that the T value, has its own scope, limited to the template only!

Function templates

This type of template should be very familiar to every Java programmer, as they look and work in the same way as generics in Java. We pass some generic class/type to the function, without any additional assumptions.

#include <iostream>
using namespace std;


template <typename T>  // T is usually used to indicate first param, U to indicate second one
T myMax(T x, T y)
{
    return (x > y) ? x: y;
}

// Based on the calls to this function in the main() method
// the template will be replaced with three separate
// implementations of the above method using ints, doubles and    // chars as input params.

int main()
{
    short myShort = 2;
    cout << myMax<int>(3, 7) << endl; // Call myMax for int
    cout << myMax<int>(myShort, 7) << endl; // ERROR - this won't compile as the params are not of the same type 
    cout << myMax<double>(3.0, 7.0) << endl; // call myMax for double
    cout << myMax<char>('g', 'e') << endl; // call myMax for char

    return 0;
}

First thing to start with is - above template is just a recipe for creating concrete function definitions. The process of that creation is called template instantiation.

Second thing to discuss is whether we should use typename or class in the template definition. Well, as far as I've read, it does not matter that much (especially in C++20). Before the usages were somehow limited when template templates were involved. More on that can be found here.

Third important concept is - there's no implicit conversion, when we're using templates! That's why in the above example the line using short variable failed miserably. In our case template expects both arguments to be the same type, and that's it. No exceptions!

To overcome the above limitation is to use explicit template argument specification (yeah, I know, long name). It is an actual hint to the compiler what will be the type of the used variable. Let's take a look at this example.

template<class T1, class T2>
void PrintNumbers(const T1& t1Data, const T2& t2Data)
{}

// This
PrintNumbers(10, 100);    // int, int
PrintNumbers(14, 14.5);   // int, double
PrintNumbers(59.66, 150); // double, int

// Can be changed to use this - and therefore limiting
// the generated specialized versions to only double one
PrintNumbers<double, double>(10, 100);    // int, int
PrintNumbers<double, double>(14, 14.5);   // int, double
PrintNumbers<double, double>(59.66, 150); // double, int

// Generated specialised version
void PrintNumbers<double, double>(const double& t1Data, const T2& t2Data)
{}

This technique should also be used, when there's no way to figure out the type used from the params of the constructor or the methods. Consider this snippet of code:

template<class T>
void PrintSize()
{
    cout << "Size of this type:" << sizeof(T);
}

// Calling it like this will cause compiler error
PrintSize();

// But with this - it's working
PrintSize<float>();

Going back to the properties of function templates - third thing to mention is that function templates can be only put into global namespace. There's no way to restrict their visibility to specified scope.

I've mentioned in the comments to the code above, that the compiler will create an actual code for every function template that's used in the code. However, there's a possibility to provide our own implementation of these functions if we want to (kind-of like default methods in Java interfaces). Take a look at the following code:

#include <iostream>
using namespace std;


template <typename T>
T myMax(T x, T y)
{
    cout << "Inside template implementation: ";
    return (x > y) ? x: y;
}

template<>
short myMax(short x, short y)
{
    cout << "Inside short implementation: ";
    return (x > y) ? x: y;
}

int main()
{
    cout << myMax((short)3, (short)7 ) << "\n" << endl; // Call myMax for short
    cout << myMax(3, 7) << "\n" << endl; // Call myMax for int
    cout << myMax(3.0, 7.0) << "\n" << endl; // call myMax for double
    cout << myMax('g', 'e') << "\n" << endl; // call myMax for char

    return 0;
}

Above technique is called specialization, and can be applied to every function template.

At the end of this section, it's worth mentioning, that there's a possibility to indicate to the compiler, which generated method should be called. I think that the following example will show what I mean.

template<class T, class U = char>
class A  {
    public:
        T x;
        U y;
        A() {   cout<<"Constructor Called"<<endl;   }
};

int main()  {
    A<char> a;  // This will call A<char, char>
    return 0;
}

The output will be:

Constructor Called

Class templates

Class templates are working in a very similar way to the function templates, although they are defined at the class level (thank you, Captain Obvious!). As an additional point, there's a possibility to implement them on a class methods outside of the class body (this technique applies also to the definition of 'normal' functions). The only thing we have to do while implementing method outside the class, is to prefix the function with a class name. Here's an example:

#include<iostream>
using namespace std;


template <typename T>
class MyClass
{
public:
    MyClass(T x, T y)
    {
        cout << "My class constructor: " + to_string(x) + " " + to_string(y) + "\n";
    }

    T myMethodOutsideOfClass();
};

template<typename T>
T MyClass<T>::myMethodOutsideOfClass()
{
    cout << "Inside short implementation \n";
    return 0;
}

int main()
{
    MyClass<int> myClass(1,2);
    myClass.myMethodOutsideOfClass();
    return 0;
}

HINT! As a Java guy I was wondering - what's the reason to define function outside the class? It's stupid and puts the class logic in two different places. Well, you are right, it is. However, coming from Java we're used to the fact, that out JARs are packed with both interfaces and implementations. In C++ (and in C), there's this whole concept of dynamic/static libraries, and a possibility to separate interface of the class using header files, and use only them during work/writing code. If we put the whole logic inside a class (while it serves also as an interface), with every change in the implementation, we got to recompile the code. With clear separation of class declaration from its definition - we don't have to. Check out this SO question for more.

There's one catch in the above - the implementation of the template must still be available to the compiler at the time of header processing! That's why in a multi-file projects, if we want to expose a header with class declaration, all the template-using functions must also be put in the same file!

When it comes to class templates, we don't need to operate only on the class level. There's also a possibility to introduce another templating solution which it called method template (pay attention to the word method, not function). I think that the code will explain it best.

#include<iostream>
using namespace std;


template <typename T>
class MyClass
{
    public:
    MyClass(T x, T y)
    {
        cout << "My class constructor: " + to_string(x) + " " + to_string(y) + "\n";
    }

    template<typename U>
    void myMethodOfClass(const U& arg)
    {
        cout << "Passed arg: " + to_string(arg) + "\n";
    }
};

int main()
{
    MyClass<int> myClass(1,2);
    myClass.myMethodOfClass(5);
    myClass.myMethodOfClass(2.0f);
    return 0;
}

As we're in the object-oriented language (more or less), we have to talk a little about inheritance too. In general, there's no problem with inheriting class templates. The only limitation here, is that we have to explicitly tell the compiler, when we want to use base-class functionality. As usual, here's the code:

#include<iostream>
using namespace std;

template<typename T>
class Foo
{
public:
    void Func() {}
};

template<typename T>
class Bar : public Foo<T>
{
public:
    void BarFunc()
    {
        // Func();   This causes compilation error
        this->Func();
        Foo<T>::Func();
    }
};

int main()
{
    Bar<int> b{};
    b.BarFunc();
}

Alias templates

We already saw that templates are great tool to reduce code size. There's another way in which templates can be useful this way - alias templates. As usual, the best way to describe this functionality is with the simple code snippet:

template <typename T, int Line, int Col>
class Matrix {
....
};

template <typename T, int Line>
using Square = Matrix<T, Line, Line>;    // That's the alias

template <typename T, int Line>
using Vector = Matrix<T, Line, 1>; 

// Code that uses above constructions
Matrix<int, 5, 3> ma;
Square<double, 4> sq;
Vector<char, 5> vec;

The solution is clear and readable. HINT! The idea of aliasing is not only related to the templates! It can be applied to any other type/definition!

Variable/Variadic templates

For Java programmers the concept should be pretty familiar - varargs used in the templates. That's it. In C++ this vararg is called template parameter pack, when used in the template, and function parameter pack. Here's the code:

// Args as a type/name is completely arbitrary and can be anything
template<typename... Args>  // this is for the template

void printMyParams(Args... args)  // this is for the function

I don't want to dive into the concept of parameter pack right now. The best resource to get an understanding how it works can be found here.
What I want to show is to how can they be used in the templates.

#include<iostream>

template <typename T, typename... Args>
T sum(T t, Args... args) {
    // [if constexpr] is evaluated during compile time
    // sizeof... is a special operator to determine the amount of params passed
    if constexpr(sizeof...(args) > 0) {  
        return t + sum(args...);
    }

    return t;
}

int main()
{
    std::cout << sum(1,2,3);
}

Executing this program will result in printed 6. In order for our example to work, an implementation of

cppdouble sum(T t)

should be provided. We avoid the need for that, by checking the amount of variable params passed to the function. As long as it is more than 0, we recursively call the function. If there's no additional params to sum, we just return the passed value. Here is the code with a separate function written.

#include<iostream>

template<typename T>
T sum(T t)
{
    return t;
}

template<typename T, typename... Args>
T sum(T t, Args... args) {
    return t + sum(args...);
}

int main()
{
    std::cout << sum(1,2,3);
}

To sum up the presentation of parameter packs, I'll show something, that is available since C++17 - folding (concept known from the functional languages) - if you're interested you can read about it on the official page.

#include<iostream>

template<typename... Args>
auto sum(Args... args) {
    return (... + args);
}

int main()
{
    std::cout << sum(1,2,3);
}

Static template class members

Every function or class can contain static members. The wide question to ask would be - how do they behave when they're used in the templates? The answer lies in the statement presented in the previous sub-chapter - templates are a recipe for creating specific functions or classes. Therefore, for every calculated combination of the types, a separate instance of function/class will be generated by the compiler. Therefore, every instance will have its own, private static member.

Concepts

In this article I will just mention them. First - because they deserve more descriptive article, than just subchapter here. Second - it's a new feature, available in C++20. Therefore, it's not widely used yet. In general - in Java we write something like this:

class MyClass<T extends SomeOtherClass>() {
      T someOtherClass;
}

At the compilation level we check, whether passed object meets the criteria of extends SomeOtherClass. It's a very powerful tool, and that's why C++ introduced it too. However, as I've said, I will write a separate article later, and link it here.

SOURCES:

CppCon 2020 'Back to Basis - Templates part 1' talk
CppCon 2020 'Back to Basis - Templates part 2' talk
Back to Basics: Function and Class Templates - Dan Saks - CppCon 2019
Bjarne Stroustrup 'Programming Principles and Practice Using C++ 2ed' book
Josh Lospinoso ‘C++ Crash Course’ book
Templates in C++ vs generics in Java article
Typename vs class
Template params and alias templates
Guide to C++ templates
Constexpr if explained
Parameter pack