Category: UFO

Author: Chloé Lourseyre
Editor: Peter Fordham

Case study

If you code in C++ regularly, you probably have encountered the following syntax:

class Foo;
Foo * make_Foo();
int main()
{
    Foo * my_foo;
    if (my_foo = make_Foo())
    {
        // ... Do things with the my_foo pointer
    }
    return 0;
}

In terms of semantics, this code is equivalent to the following:

class Foo;
Foo * make_Foo();
int main()
{
    Foo * my_foo = make_Foo();
    if (my_foo)
    {
        // ... Do things with the my_foo pointer
    }
    return 0;
}

This is today’s subject: assignment is an expression.

How does it work?

What is the value of such expression?

If we run the following code, we’ll have the answer:

int main()
{
    int foo = 2;
    std::cout << (foo = 3) << std::endl;
    return 0;
}

The standard output prints 3.

So we can say that the assignment expression is evaluated as the assigned variable, after it is assigned¹.

One typo away from catastrophe

Let’s say that we have three variables, a, b and c. You want the value of a to be true if (and only if) b and c are equal.

So we will write this:

bool a, b, c;
// ...
a = b == c;

But, we are not very far away from a serious typo. This one:

bool a, b, c;
// ...
a = b = c;

This code will compile, and won’t give you the intended result. How come?

The expression a = b = c are two assignment operations within one expression. According to the C++ Operator Precedence Table, the associativity of = is from right to left. So the expression a = b = c is equivalent to a = (b = c).

Since (b = c) is evaluated (as seen earlier) as the value of b after assignment, a = b = c; is equivalent to b = c; a = b;

If you then use a as a boolean, it will be evaluated as true if (and only if) c is also true.

Conclusion about a = b = c

There may be cases where this syntax (with two = within a single expression) is useful, but most of the time I find it obtuse and confusing.

As of today, there is no way to efficiently prevent a typo like this from happening (adding parenthesis will not prevent the compilation in case of a typo is made). All you can do is open your eyes wide and use constant variables as much as possible (if b is const, then the code fails to compile if there is a typo)².

The assignment operation returns an lvalue

I’ll finish this article by showing that the assignation operation is an lvalue.

Let’s take the a = b = c back and add parenthesis around the a = b.

int main()
{
    int a = 1, b = 2, c = 3;
    (a = b) = c;
    std::cout << a << b << c << std::endl;
    return 0;
}

This compiles and prints the following result: 323.

That means that a has been assigned the value of b, then the value of c. The expression a = b is indeed a lvalue.

void foo(int&);
int main()
{
    int a = 1, b = 2;
    foo(a = b); // Compiles because `a = b` is an lvalue
    foo(3); // Does not compile because `3` is an rvalue
    return 0;
}

More specifically, the assignment operation (of fundamental types) returns a reference to the resulting variable.

Assignment operation for user-defined types

However, when you define an operator=, the standard allows you to return any type you want (refer to the Canonical implementations section of operator overloading – cppreference.com for more details³).

You can of course return a reference to the assigned object, like so:

struct Foo
{
    Foo& operator=(const Foo&) { return *this; }
};
int main()
{
    Foo a, b, c;
    a = b = c;
    return 0;
}

You can also return a value instead of a reference:

struct Foo
{
    Foo operator=(const Foo&) { return *this; }
};
int main()
{
    Foo a, b, c;
    a = b = c; // Also works, but a copy is made
    return 0;
}

Since the result is copied, the assignment b = c becomes a rvalue. Indeed, if you now try to take a reference out of it, you have a compilation error:

struct Foo
{
    Foo operator=(const Foo& other) 
    { 
        val = other.val; 
        return *this; 
    }
    int val;
};
int main()
{
    Foo b = {1}, c = {2};
    Foo & a = b = c; // Does not compile because here, (b = c) is an rvalue
    return 0;
}

This code would compile if operator= returned a Foo& instead of a Foo.

You can also return nothing (using void as return value). In that case, you cannot write a = b = c at all.

struct Foo
{
    void operator=(const Foo&) {  }
};
int main()
{
    Foo a, b, c;
    a = b = c; // Does not compile because (b = c) returns nothing
    return 0;
}

This can be used as a good safeguard against the a = b = c syntax⁴.

About declarations

There are specific cases where you can write a declaration, within another statement (such as the assignment we have seen earlier).

You can use this specific syntax in most flow control statements (like if, while, switch and, of course for) and within function calls.

For instance, the very first example of this post can also be written like this⁵:

class Foo;
Foo * make_Foo();
int main()
{
    if (Foo * my_foo = make_Foo())
    {
        // ... Do things with the my_foo pointer
    }
    return 0;
}

However, the declaration itself is neither a lvalue nor a rvalue.

You can’t write this:

int main()
{
    int a = 1, c = 3;
    a = (int b = c); // Does not compile
    return 0;
}

nor this:

int main()
{
    int b = 2, c = 3;
    (int a = b) = c; // Does not compile
    return 0;
}

This is specified as “init-statement” in the standard, so when you see init-statement written in a prototype, you know you can put a declaration in there:

Wrapping up

Syntaxes like a = b = c and if (a = b) are intentional and clearly defined in the standard. However, they are alien to most developers and are so rarely used that they can easily be misleading.

Bugs can occur because the symbol = really looks like ==, so be wary of that. If you want to avoid it with your user-defined types, you can declare the operator= function returning void so the a = b = c syntax becomes invalid, but this is not possible with fundamental types, and is a constraint on its own.

Thanks for reading and see you next time!

Author: Chloé Lourseyre
Editor: Peter Fordham

Addendum

Notes

1. It is in fact evaluated as a reference to the variable, and not the value of the variable. This will be demonstrated further in the article.

2. You can actually activate specific warnings to prevent specific cases (for instance, -Wparentheses can be used with GCC to avoid assignment inside a flow control statement), but that doesn’t cover every case (typically a = b = c cannot be warned out) and sometimes you may not want to activate them depending on your appreciation of this syntax.

3. The site cppreference.com says that “for example, assignment operators return by reference to make it possible to write a = b = c = d, because the built-in operators allow that.”. However, there is no mention of this specific intention in the 4th edition of The C++ Programming Language by Bjarne Stroustrup. I suspect this is a free interpretation.

4. You can, as you may have guessed, also return any type you want, if you have very specific needs. The prototype int operator=(const Foo&); (member function of class Foo) is valid. This can be useful, for instance, if you want to return an error code.

5. There is a difference in pragmatics in terms of scope (that is not the subject of today’s), because in the first example, the my_foo variable only lives within the if block, whereas in the first examples, it lives through the scope of main. But since it’s technically the same in this specific case (because there is nothing after the if block), I deem it not necessary to elaborate.

Author: Chloé Lourseyre
Editor: Peter Fordham

This article is a little compilation¹ of strange behaviors in C++, that would not make a long enough article on their own.

Static casting an object into their own type can call the copy constructor

When you use static_cast, by defaut (i.e. without optimizations activated) it calls the conversion constructor of the object you are trying to cast into (if it exists).

For instance, in this code.

class Foo;
class Bar;

int main()
{
    Bar bar;
    static_cast<Foo>(bar);
}

The highlighted expression would call the following constructor (if existent): Foo(const Bar &).

So far so good, and there is a good chance that you already knew that.

But do you know what happens if you try to static cast an object into its own type?

Let’s take the following code:

struct Foo
{
    Foo(): vi(0), vf(0) {};
    Foo(const Foo & other): vi(other.vi), vf(other.vf) {};
    long vi;
    double vf;
};

int main()
{
    Foo foo1, foo2, foo3;
    foo2 = foo1;    
    foo3 = static_cast<Foo>(foo1);

    return 0;
}

And look at the assembly of the highlighted lines

Line 12

        mov     rax, QWORD PTR [rbp-32]
        mov     rdx, QWORD PTR [rbp-24]
        mov     QWORD PTR [rbp-48], rax
        mov     QWORD PTR [rbp-40], rdx

Line 13

        lea     rdx, [rbp-32]
        lea     rax, [rbp-16]
        mov     rsi, rdx
        mov     rdi, rax
        call    Foo::Foo(Foo const&) [complete object constructor]
        mov     rax, QWORD PTR [rbp-16]
        mov     rdx, QWORD PTR [rbp-8]
        mov     QWORD PTR [rbp-64], rax
        mov     QWORD PTR [rbp-56], rdx

We can see that when we static cast the object foo1, it calls the copy constructor of Foo as if the copy constructor was actually a “conversion constructor of a type into itself”.

(Done using GCC 11.2 x86-64, Compiler Explorer (godbolt.org))

Of course, this behavior will disappear as soon as you put an optimization option in the compiler.

This is typically useless knowledge² and something you doesn’t encounter often in real life (I happen to have encountered it once, but this was an unfortunate accident)

Static casts can call several conversion constructors

Talking about conversion constructors, they can be transitive when static_cast is used.

Take the following classes:

struct Foo
{  Foo() {};  };

struct Bar
{  Bar(const Foo & other) {};  };

struct FooBar
{  FooBar(const Bar & other) {};  };

struct BarFoo
{  BarFoo(const FooBar & other) {};  };

We have four types: Foo, Bar, FooBar, and BarFoo. The conversion constructors say we can convert a Foo into a Bar, a Bar into a FooBar, and a FooBar into a BarFoo.

If we try to execute the following code:

int main()
{
    Foo foo;
    BarFoo barfoo = foo;
    return 0;
}

There is a compilation error on line 4: conversion from 'Foo' to non-scalar type 'BarFoo' requested.

However, if we static_cast foo into a FooBar, as such:

int main()
{
    Foo foo;
    BarFoo barfoo = static_cast<FooBar>(foo);
    return 0;
}

The program compiles.

If we now take a look at the assembly code associated with line 4:

        lea     rdx, [rbp-3]
        lea     rax, [rbp-1]
        mov     rsi, rdx
        mov     rdi, rax
        call    Bar::Bar(Foo const&) [complete object constructor]
        lea     rdx, [rbp-1]
        lea     rax, [rbp-2]
        mov     rsi, rdx
        mov     rdi, rax
        call    FooBar::FooBar(Bar const&) [complete object constructor]
        lea     rdx, [rbp-2]
        lea     rax, [rbp-4]
        mov     rsi, rdx
        mov     rdi, rax
        call    BarFoo::BarFoo(FooBar const&) [complete object constructor]

There are no less than 3 conversions generated by that single statement.

(Done using GCC 11.2 x86-64, Compiler Explorer (godbolt.org))

Hold up!

You may be wondering why I didn’t cast foo into a BarFoo and I only cast it into a FooBar using the static_cast.

If we try and compile the following code:

int main()
{
    Foo foo;
    BarFoo barfoo = static_cast<BarFoo>(foo);
    return 0;
}

We end up with a compilation error!

<source>:16:44: error: no matching function for call to 'BarFoo::BarFoo(Foo&)'

In fact, static_cast is not transitive

What really happens is the following:

The expression static_cast<FooBar>(foo) tries to call the following constructor: FooBar(const Foo&). However, it doesn’t exist, the only conversion constructor FooBar has is FooBar(const Bar&). But, there is a conversion available from Foo to Bar, so the compiler implicitly converts foo into a Bar to call the FooBar(const Bar&).

Then we try to assign the resulting FooBar to a BarFoo. Or, more precisely, we try to construct a BarFoo using a FooBar, which calls the BarFoo(const FooBar&) constructor.

That is why there is a compilation error when we try to cast a Foo directly into a BarFoo.

In fact, static_cast is not really transitive.

What to do with this information?

Implicit conversion can happen anywhere. Since static_cast (and any cast) is, pragmatically³, a “function call” (in the sense that it takes an argument and returns a value) it gives two opportunities for the compiler to try an implicit conversion.

The behavior of C-style casts

Using C-style casts is a fairly widespread bad practice in C++. It really should have made into this old article A list of bad practices commonly seen in industrial projects.

Many C++ developers don’t understand the intricacies of what C-style casts actually do.

How do casts work in C?

If I remember right, casts in C has three uses.

First, they can convert one scalar type into another, like this:

int toto = 42;
printf("%f\n", (double)toto);

But this can only be used to convert scalar type. If we try to convert a C struct into another using a cast:

#include <stdio.h>

typedef struct Foo
{
    int toto;
    long tata;
} Foo;

typedef struct Bar
{
    long toto;
    double tata;
} Bar;


int main()
{
    Foo foo;
    foo.toto = 42;
    foo.tata = 666;
    
    Bar bar = (Bar)foo;
    
    printf("%l %d", bar.toto, bar.tata);

    return 0;
}

We obtain the following compilation error:

main.c:22:5: error: conversion to non-scalar type requested
   22 |     Bar bar = (Bar)foo;
      | 

(Source: GDB online Debugger | Code, Compile, Run, Debug online C, C++ (onlinegdb.com))

Second, they can be used to reinterpret a pointer into a pointer of another type, like this:

#include <stdio.h>

typedef struct Foo
{
    int toto;
    long tata;
    int tutu;
} Foo;

typedef struct Bar
{
    long toto;
    int tata;
    int tutu;
} Bar;


int main()
{
    Foo foo;
    foo.toto = 42;
    foo.tata = 666;
    foo.tutu = 1515;
    
    Bar* bar = (Bar*)&foo;
    
    printf("%ld %d %d", bar->toto, bar->tata, bar->tutu);

    return 0;
}

This prints the following output⁴:

42 666 0

(Source: GDB online Debugger | Code, Compile, Run, Debug online C, C++ (onlinegdb.com))

And finally, it can be used to add or remove a const qualifier:

#include <stdio.h>

int main()
{
    const int toto = 1;
    int * tata = (int*)(&toto);
    *tata = 42;
    
    printf("%d", toto);

    return 0;
}

This prints 42.

(Source: GDB online Debugger | Code, Compile, Run, Debug online C, C++ (onlinegdb.com))

This also works on structs.

And that’s pretty much all⁵.

So what happens in C++

C++ has its own cast operators (mainly static_cast, dynamic_cast, const_cast, and reinterpret_cast, but also many other casts like *_pointer_cast, etc.)

But C++ was also intended to be backward-compatible with C (at first). So we needed a way to implement the C-style casts so that they would work similarly to C casts, all in the C++ new way of casting.

So in C++, when you do a C-style cast, the compiler tries each one of the five following cast operations (in that order), and uses the first that works:

• const_cast
• static_cast
• static_cast followed by const_cast
• reinterpret_cast
• reinterpret_cast followed by const_cast

More details here: Explicit type conversion – cppreference.com.

Why this is actually bad?

Most C++ developers agree that it is really bad practice to use C-style casts in C++. Here are the reasons why: it is not explicit what the compiler will do. The C-style cast will often work, even when there is an error, and silence that error. You always want only one of these casts, so you should explicitly call it. That way, if there is any mistake there’s a good chance the compiler will catch it. Objectively, there are absolutely no upsides to using a C-style cast.

Here is a longer argument against C-style casts: Coding Standards, C++ FAQ (isocpp.org).

Wrapping up

Casting is a delicate operation. It can be costly (more than you think because it gives room for implicit conversions) and still today, there are a lot of people using C-style without knowing how bad it is.

It is tedious, but we need to understand of casts work and the specificities of each one.

Thanks for your attention and see you next time!

Author: Chloé Lourseyre
Editor: Peter Fordham

Addenda

Online compilers links

Static casting an object into their own type can call the copy constructor

• Assembly shows copy constructor is called (godbolt.org)

Static casts can call several conversion constructors

• Assembly shows that 3 conversion constructors are called (godbolt.org)

The behavior of C-style casts

• Trying to cast a struct into another in C (onlinegdb.com)
• Pointer casting in C (onlinegdb.com)
• Const cast in C (onlinegdb.com)

Notes

1. Pun intended.
2. If you know a case where it is useful, please share in the comments.
3. In the linguistic field, pragmatics is the study of context (complementary to semantics, which studies the meaning, and many other fields). In terms of programming language, pragmatics can be interpreted as how features interact with others in a given context. In our example, a static_cast can hardly be considered a function call in the semantics sense, but act as one in the interactions it has with its direct environment (as it is explained in the paragraph). The technical truth is in-between: for POD it is not a function call, but for classes that define a copy-constructor it is.
4. I won’t explain in detail why it prints 0 instead of 1515 for the value of tutu: just know that because we reinterpret the data stored in memory, reading a Foo as if it was a Bar leads to errors.
5. I am not as fluent in C as I am in C++. I may have forgotten another use of C casts. If so, please contribute in the comments.