Yet another reason to not use printf (or write C code in general)

Author: ChloƩ Lourseyre

Recently, Joe Groff @jckarter tweeted a very interesting behavior inherited from C:

Obviously, it’s a joke, but we’re gonna talk more about what’s happening in the code itself.

So, what’s happening?

Just to be 100% clear, double(2101253) does not actually double the value of 2101253. It’s a cast from int to double.

If we write this differently, we can obtain this:

#include <cstdio>

int main() {
    printf("%d\n", 666);
    printf("%d\n", double(42));
}

On the x86_64 gcc 11.2 compiler, the prompt is as follows:

666
4202506

So we can see that the value 4202506 has nothing to do with the 666 nor the 42 values.

In fact, if we launch the same code in the x86_64 clang 12.0.1 compiler, things are a little bit different:

666
4202514

You can see the live results here: https://godbolt.org/z/c6Me7a5ee

You may have guessed it already, but this comes from line 5, where we print a double as an int. But this is not some kind of conversion error (of course that your computer knows how to convert from double to int, it will do it fine if this was what was happening), the issue comes from somewhere else.

The truth

If we want to understand how it works that way, we’ll have to take a look at the assembly code (https://godbolt.org/z/5YKEdj73r):

.LC0:
        .string "%d\n"
main:
        push    rbp
        mov     rbp, rsp
        mov     esi, 666
        mov     edi, OFFSET FLAT:.LC0
        mov     eax, 0
        call    printf
        mov     rax, QWORD PTR .LC1[rip]
        movq    xmm0, rax
        mov     edi, OFFSET FLAT:.LC0
        mov     eax, 1
        call    printf
        mov     eax, 0
        pop     rbp
        ret
.LC1:
        .long   0
        .long   1078263808

(use this Godbolt link to have a clearer matching between the C++ code and the assembly instructions: https://godbolt.org/z/5YKEdj73r)

In the yellow zone of the assembly code (lines 6-to 9, the equivalent to printf("%d\n", 666);) we can see that everything’s fine, the 666 value is put in the esi register and then the function printf is called. So it’s an educated guess to say that when the printf function reads a %d in the string it is given, it’ll look in the esi register for what to print.

However, we can see in the blue part of the code (lines 10 to 14, the equivalent to printf("%d\n", double(42));) the value is put in another register: the xmm0 register. Since it is given the same string as before, it’s pretty guessable that the printf function will look into the esi register again, whatever there is in there.

We can prove that statement pretty easily. Take the following code:

#include <cstdio>

int main() {
    printf("%d\n", 666);
    printf("%d %d\n", double(42), 24);
}

It’s the same code, with an additional integer that is print in the second printf instruction.

If we look at the assembly (https://godbolt.org/z/jjeca8qd7):

.LC0:
        .string "%d %d\n"
main:
        push    rbp
        mov     rbp, rsp
        mov     esi, 666
        mov     edi, OFFSET FLAT:.LC0
        mov     eax, 0
        call    printf
        mov     rax, QWORD PTR .LC1[rip]
        mov     esi, 24
        movq    xmm0, rax
        mov     edi, OFFSET FLAT:.LC0
        mov     eax, 1
        call    printf
        mov     eax, 0
        pop     rbp
        ret
.LC1:
        .long   0
        .long   1078263808

The double(42) value still goes into the xmm0 register, and the 24 integer, logically, ends up in the esi register. Thus, this happens in the output:

666
24 0

Why? Well, since we asked for two integers, the printf call will look into the first integer register (esi) and print its content (24, as we stated above), then look in the following integer register (edx) and print whatever is in it (incidentally 0).

In the end, the behavior we see occurs because of how the x86_64 architecture is made. If you want to learn more about that, follow these links:

What does the doc say?

The truth is that according to the reference (printf, fprintf, sprintf, snprintf, printf_s, fprintf_s, sprintf_s, snprintf_s – cppreference.com):

If a conversion specification is invalid, the behavior is undefined.

And this same reference is unambiguous about the %d conversion specifier:

converts a signed integer into decimal representation [-]dddd.
Precision specifies the minimum number of digits to appear. The default precision is 1.
If both the converted value and the precision are ā€‹0ā€‹ the conversion results in no characters.

So, giving a double to a printf argument where you are supposed to give a signed integer is UB. So it was our mistake to write this in the first place.

This actually generates a warning with clang. But with gcc, you’ll have to activate -Wall to see any warning about that.

Wrapping up

The C language is a very, very old language. It’s older than the C++ (obviously) that is itself very old. As a reminder, the first edition of the K&R has been printed in 1978. This was thirteen years before my own birth. And unlike us humans, programming languages don’t age well.

I could have summarized this article with a classic “don’t perform UB”, but I think it’s a bit off-purpose this time. So I’ll go and say it: don’t use printf at all.

The problem is not with printf itself, it’s with using a feature from another language1 that was originally published forty-three years ago. In short: don’t write C code.

Thanks for reading and see you next week!

1. Yeah, like it or not, but C and C++ and different languages. Different purpose, different intentions, different meta. That is exactly why I always deny job offers that have the tag “C/C++” because they obviously can’t pick a side.

Author: ChloƩ Lourseyre

You shouldn’t assume accessors are fast

Author: ChloƩ Lourseyre

“Accessors are fast.” I heard this leitmotiv so many times over the years that I couldn’t not write about it.

Explanation

What’s the use for accessors?

During the researches I made for this article, I was surprised that there actually is a formal definition of accessors1.

You can find this definition in section Ā§ 18.3.5 Accessor functions of the fourth edition of The C++ Programming Language (Bjarne Stroustrup).

Long story short, the definition says that, though is unadvised to abuse that feature, you can design a method to read and edit private attributes of a class to write a clean algorithm (I’m paraphrasing).

So, in short, accessors are used as an interface between the private members of a class and the user of this class.

Like any kind of interface, accessors can thus obfuscate how the actual access of the private members is done, to encapsulate more complex code and ease how the class is used.

1. I’m not discussing the fact that there is a pseudo-consensual definition of accessors. However, since this article aims to deconstruct that definition, I won’t rely on it to build my arguments. You can find this pseudo-consensual definition in the following paragraph, where I describe why it is a bad one.

People don’t use accessors properly…

Every day I see people using accessors improperly. Here are a few examples:

  • Writing the simplest get/set for every member of a class without thinking. If your class makes every attributes available with no subtlety and nothing else is private, then it’s not a class, it’s a struct2.
  • Writing accessors that are never used. Don’t write something you don’t need, it’s just polluting the codebase.
  • Realizing that there are not accessors for a given attribute and implementing them without questioning. Sometimes (often), there is a good reason that an attribute doesn’t have accessors.
  • Declaring a getter that is not const (even though it should be). By default, make everything const unless you need it non-const.
  • Declaring a getter that is const even though it shouldn’t be. This one is very rare, but I did see several times writing a dangerous const-cast just to make a getter const. You should avoid writing const-casts at all costs (and the examples I recall there wasn’t a good reason for it).

There are a lot of other bad practices that are too verbose to describe in this article (which purpose is not to teach you to use accessors properly).

2. Here, I abusively use the word class to name a data structure with private members and the struct to name a data structure that is nothing more than a data bucket. This is done on purpose to smooth the read of the article.

…leading to false assumptions

Bad practices lead to a bad way of thinking. And a bad way of thinking leads to false assumptions.

The most widespread false assumption over accessors is the following:

All accessors should be fast to execute.

Assuming accessors are fast is a useless limitation

Without talking about the fact that it can be harmful (if you use a function thinking it is fast, the day it is not you may have a bad surprise), by making this assumption you put a limitation on yourself.

This limitation is not effectively useful (at best, it saves you the time to read the documentation of the accessors — which should not be overlooked anyway), it restrains your ability to innovate and do something useful with your accessor.

Demonstration with a useful pattern

I’m going to show you a pattern that I love to use because it is really useful and saves a lot of lines of code.

Consider this: you have to implement a class that, given several input parameters, provides several outputs (two in our example). You need to use this class to fill two arrays with the outputs, but the parameters don’t always change (so you don’t always have to perform the computation). Since the computation is time-consuming, you don’t want to re-compute when you don’t have to3.

One (naĆÆve) way to do this would be that (full code here https://godbolt.org/z/a4x769jra) :

class FooBarComputer
{
public:
    FooBarComputer();

    // These update the m_has_changed attribute if relevant
    void set_alpha(int alpha);
    void set_beta(int beta);
    void set_gamma(int gamma);

    int get_foo() const;
    int get_bar() const;

    bool has_changed() const;
    void reset_changed();

    void compute();

private:
    int  m_alpha, m_beta, m_gamma;
    int m_foo, m_bar;
    bool m_has_changed;
};


//  ...


//==============================
bool FooBarComputer::has_changed() const
{
    return m_has_changed;
}

void FooBarComputer::reset_changed()
{
    m_has_changed = false;
}


//==============================
// Output getters
int FooBarComputer::get_foo() const
{
    return m_foo;
}

int FooBarComputer::get_bar() const
{
    return m_bar;
}


//  ...


//==============================
// main loop
int main()
{
    std::vector<int> foo_vect, bar_vect;
    FooBarComputer fbc;

    for (int i = 0 ; i < LOOP_SIZE ; ++i)
    {
        fbc.set_alpha( generate_alpha() );
        fbc.set_beta( generate_beta() );
        fbc.set_gamma( generate_gamma() );

        if ( fbc.has_changed() )
        {
            fbc.compute();
            fbc.reset_changed();
        }

        foo_vect.push_back( fbc.get_foo() );
        bar_vect.push_back( fbc.get_bar() );
    }
}

However, it is possible to write a better version of this class by tweaking the getter, like so (full code here https://godbolt.org/z/aqznsr6KP):

class FooBarComputer
{
public:
    FooBarComputer();

    // These update the m_has_changed attribute if relevant
    void set_alpha(int alpha);
    void set_beta(int beta);
    void set_gamma(int gamma);

    int get_foo();
    int get_bar();

private:
    void check_change();
    void compute();

    int  m_alpha, m_beta, m_gamma;
    int m_foo, m_bar;
    bool m_has_changed;
};


//  ...


//==============================
void FooBarComputer::check_change()
{
    if (m_has_changed)
    {
        compute();
        m_has_changed = false;
    }
}


//==============================
// Output getters
int FooBarComputer::get_foo()
{
    check_change();
    return m_foo;
}

int FooBarComputer::get_bar()
{
    check_change();
    return m_bar;
}


//  ...


//==============================
// main loop
int main()
{
    std::vector<int> foo_vect, bar_vect;
    FooBarComputer fbc;

    for (int i = 0 ; i < LOOP_SIZE ; ++i)
    {
        fbc.set_alpha( generate_alpha() );
        fbc.set_beta( generate_beta() );
        fbc.set_gamma( generate_gamma() );

        foo_vect.push_back( fbc.get_foo() );
        bar_vect.push_back( fbc.get_bar() );
    }
}

Here are the benefits:

  • The main code is shorter and clearer.
  • You don’t need to make the compute() public anymore.
  • You don’t need has_changed(), instead, you have a check_change() that is private.
  • Users of your class will be less likely to misuse it. Since the compute() is now lazy, you are sure that no one will call the compute() recklessly.

This is that last point that is the most important. Any user could have made the mistake to omit the if conditional in the first version of the loop, rendering it inefficient.

3. If you want, you can imagine that the parameters change only once a hundred times. Thus, this is important to not call the compute() every time.

Isn’t it possible to do otherwise?

The most recurring argument I hear about this practice is the following: “Well, why don’t you just name your method otherwise? Like computeFoo()?”.

Well, the method does not always perform the computation so it’s wrong to call it that way. Plus, semantically, compute refers to a computation and does not imply that the value is returned. Even if some people do it, I don’t like to use the word compute that way.

“Then call it computeAndGetFoo() and be done with it!”

Except, again, it’s not what it does. It does not always compute, so a more appropriate name would be sometimesComputeAndAlwaysGet(), which is plain ridiculous for such a simple method.

“Then find a proper name!”

I did. It’s getFoo(). It’s what it does, it gets the foo. The fact that the compute() is lazy does not change the fact that it’s a getter. Plus, this is mentioned in the comments that the get may be costly, so read the documentation and everything will be fine.

“Couldn’t you put the check into the compute() instead of the getter?”

I could have, but to what end? Making the compute() public is useless since you need the getters to access the data.

There is a way to do otherwise…

There actually is a way to do otherwise, which is especially useful when you also need a getter than you are sure will never call the compute (this is useful if you need a const getter for instance).

In that case, I advise that you don’t use the same name for both getters, because they don’t do the same thing. Using the same name (with the only difference being the constness) will be confusing.

I personally use the following names:

  • getActiveFoo()
  • getPassiveFoo()

I like this way of writing it because you explicitly specify if the getter is potentially costly or not. Moreover, it also implies that the passive getter may give you an outdated value.

Plus, anyone who tries to call getFoo() will not succeed and have to choose between both versions. Forcing the user to think about what they write is always a good thing.

Most importantly: spread the word

Since it is useful to put performance-sensitive code in getters, you will find developers who do it.

The most dangerous behavior is ignoring that fact and letting other people assume that accessors are fast to execute.

You should spread the word around you that accessors are, at the end of the day, like any other method: they can be long to execute, and everyone must read the associated documentation before using them.

In this article, I talked about execution time performance, but this also applies to any other form of performance: memory consumption, disk access, network access, etc.

Thank you for reading and see you next week!

Author: ChloƩ Lourseyre

Don’t use raw loops

Author: ChloƩ Lourseyre

Intentions

Sean Parent once said “No raw loops“. This was eight years ago.

Today, among the people who don’t have a strong C++ background, almost nobody knows this statement (let alone to know who Sean Parent is). As a result, in 2021, many C++ projects use tons of raw loops and almost no algorithms.

This article intends to teach you, the people who still use raw loops in 2021, why and how to use algorithms instead.

Resources

This subject has been covered by many C++ experts already, so if you feel technical and have some free time, check the following resources:

Sean Parent’s talk that contains the no raw loops statement:
C++ Seasoning | GoingNative 2013 | Channel 9 (msdn.com)

A Jason Turner’s talk about code smells (including the use of raw loops):
C++ Code Smells – Jason Turner – CppCon 2019 – YouTube

Jonathan Boccara’s talk about STL algorithms:
CppCon 2018: Jonathan Boccara ā€œ105 STL Algorithms in Less Than an Hourā€ – YouTube.

As a bonus, here is a map representation of the STL algorithms:
The World Map of C++ STL Algorithms – Fluent C++ (fluentcpp.com).

What are raw loops?

What we call raw loops are you most basic design of loops. It is usually the use of the keywords for, while, or do while accompanied by a block of code.

Raw loops are opposed to algorithms, that are encapsulated loops (or non-loops, how could you know since it’s encapsulated?) serving a specific or generic purpose and that can be called using dedicated functions.

Why you should not use raw loops

It’s a matter of semantics. A raw loop can only express the technical fact that it’s a loop, you write how your algorithm proceeds.

When you call an algorithm, you write what you intend, you write what you want to obtain.

For example, let’s look at this sample of code:

//...

for (size_t i = 0; i < my_vect.size() && predicate(my_vect, i) ; ++i)
{
    //...
}

//...

This tells you that you perform a loop, indexed over a vector and controlled by a custom predicate, but no more. It doesn’t tell you what the loop does, and what result is expected from it. You’ll have to study the body of the loop to know that.

Now let’s look at this algorithm call:

//...

auto it_found = std::find_if(cbegin(my_vect), cend(my_vect), predicate);

//...

Even if you don’t know how find_if() proceeds, you understand it will return an element of my_vect that matches the condition predicate(). You understand what it does, not how it is done.

From there, there are several points to consider:

  • Algorithms raise the level of abstraction and help you understand the intention behind the code.
  • Good semantics leads to good readability, good readability leads to better maintainability, better maintainability leads to fewer regressions.
  • Calling an algorithm is less verbose than re-writing it.
  • Raw loops are prone to several common mistakes, like off-by-one, empty loops, naive complexity, etc.

What to do when there is no existing algorithm?

There are times when you need an algorithm to perform a specific task, but this is so specific that none of the existing algorithms is suitable. What to do in this case?

Combine algorithms into a new one

Often, your specific algorithm can be resolved by doing a combination of existing algorithms, or by implementing a specific version of an existing one. To do so, just implement a function that does the combination for you and give it an explicit name. Then anyone can call it like any algorithm.

For example, you need to verify if, in a vector, all elements that match condition A also match condition B. To do this, you can use the algorithm std::all_of with a custom predicate:

template< typename Iterator, typename PredA, typename PredB >
bool both_or_none( Iterator first, Iterator last, PredA & predA, PredB & predB )
{
    auto pred = [&predA,&predB](const auto& elt)
    {
        return predA(elt) == predB(elt); 
    };
    return all_of(first, last, pred);
}

The body of the algorithm is pretty short: it creates a function that combines both predicates to implement our specific condition, then applies std::all_of(), the algorithm that verifies that the condition is true on every element of the collection.

Write a raw loop inside a function

There are some times when trying to combine existing algorithms is futile and may feel forced and artificial.

What you need to do when this occurs is to write your own raw loop in a dedicated function, that will act as your algorithm. Be sure to give it an explicit name.

For example, you have a collection and you need to get the maximum element that matches a condition. This is what the algorithm max_if() would be if it existed.

However, you can’t pull it out easily by combining existing algorithms. You would first need to get the subset of your collection that matches the condition, then calling std::max() on it. But the only way1 to get that subset is to use a std::copy_if, which copies elements. Copies may be expensive so you don’t want that.

What to do then? Write the raw loop that implements the max_if() yourself, and encapsulate it in a function:

template< typename Iterator, typename Pred >
constexpr Iterator max_if( Iterator first, Iterator last, Pred & pred )
{
    Iterator max_element = last;
    for (auto it = first ; it != last ; ++it)
    {
        if (pred(*it) && (max_element == last || *it > *max_element))
            max_element = it;
    }
    return max_element;
}

Then, the use of max_if will be semantically explicit, matching all the upsides of a true algorithm.

1There actually are other ways, like using find_if then remove in successions, but they are pretty much worse.

STL algorithms examples

There are plenty of algorithms in the STL. I suggest you be curious and explore by yourself: Algorithms library – cppreference.com.

As an appetizer, here are a few very basic and common algorithms that, if you don’t already know them, should learn about.

  • std::find(): Searches for an element equal to a given value.
  • std::find_if(): Searches for an element for which a given predicate returns true.
  • std::for_each(): Applies the given function object to the result of dereferencing every iterator in the range, order.
  • std::transform(): Applies the given function to a range and stores the result in another range, keeping the original elements order.
  • std::all_of(): Checks if the given unary predicate returns true for all elements in the range.
  • std::any_of(): Checks if the given unary predicate returns true for at least one element in the range.
  • std::copy_if(): Copies the elements for which the given predicate returns true.
  • std::remove_if(): Removes the elements for which the given predicate returns true.
  • std::reverse(): Reverses the order of the elements in the range.
  • And many more…

If you want to go further, here is a one-hour talk presenting more than a hundred algorithms: CppCon 2018: Jonathan Boccara ā€œ105 STL Algorithms in Less Than an Hourā€ – YouTube

Wrapping up

Many C++ experts agree that loops are to disappear in the higher abstraction levels, only used to write lower-level algorithms. This statement is not an absolute, but an ideal to keep in mind when you code.

If like many C++ developers, you tend to use raw loops instead of algorithms, you certainly should check the resources provided in this article. As you get familiar with the most basic algorithm and begin to use them in practice, you’ll find them more and more convenient.

Thanks for reading and see you next week!

Author: ChloƩ Lourseyre

A list of bad practices commonly seen in industrial projects

Author: ChloƩ Lourseyre

If you ever worked in a company-size software project (with numerous developers), there is a good chance that the codebase was, at least, pretty messy.

In these days, most industrial C++ developers are not experts. You will often work with developers with a Java or Python background, people who just learnt C++ at school and don’t really care that much about the language and old developers who code in “C with classes” instead of C++.

Having worked on a few industrial projects myself, I realized there are some recurring patterns and bad practices. If you happen to teach your coworkers to avoid these bad practices, you will all take a huge step toward a beautiful codebase and it will be beneficial to you, your coworkers and your project.

Here is a non-exhaustive list of these common bad practices.

Bad practice : Overly long functions

I am not one to set hard restrictions over the number of lines in a function. However, when a function reach more that a thousand lines (or even tens of thousands of lines), it is time to put a stop at it.

A function is a architectural block. If it is too big, it will be harder to understand. If is it split into different blocks, with explicit names and comprehensible comments, your mind will be able to turn its attention to each blocks in turns, which are individually easier to understand, and will put them back together to understand the globality of the function.

Sometimes, your function is just calling auxiliary functions in succession, and that’s ok. It’s short, easy to understand, and each auxiliary function, which are small, are also easy to understand.

To solve a big problem, split it in several smaller problems.

The limit I generally use is 200 lines per functions. Sometimes more, sometimes less.

Bad practice : Create classes when you don’t need to

This is something that is surprisingly fairly common, and probably due to other object-oriented languages that force you to use classes for everything.

There are two ways this bad practice can occur :

Full-static classes (sometimes with constructors)

It is easier to illustrate with an example, so here we go :

class MyMath
{
public:
    MyMath();
    ~MyMath();
    static int square(int i);
};

MyMath::MyMath()
{
}

MyMath::~MyMath()
{
}

int MyMath::square(int i)
{
    return i*i;
}

int main()
{
    MyMath mm;
    int j = mm.square(3);
    return j;
}

Here are the problematic points :

  • Why would you implement useless constructor and destructor, where you just could have used the default ones ?
  • Why would you implement a constructor and a destructor for a full-static class ?
  • Why would you instantiate an object just to call the static method of the class ?
  • Why would you use class at all, where a namespace would suffice ?

Here is what should have been written :

namespace MyMath
{
    int square(int i);
};

int MyMath::square(int i)
{
    return i*i;
}

int main()
{
    int j = MyMath::square(3);
    return j;
}

Shorter, better, smarter.

True, sometimes a full-static class can be useful, but in situations like that example, they are not.

There is no benefit in using a class where you could not. If you are worried that the namespace could be used as a class in the future (with attributes and methods), just remember this little rule that every one should know :

Do not code thinking of an hypothetical future that may or may not occur. The time you spend coding in anticipation is most certainly wasted, as you can always refactor later.

Fully transparent classes

I put this one in second because it is the most controversial.

Just to clear : the only difference between class and struct is that, by default, the members of a class are private and the members of a struct are public. This is truly the only difference.

So, if your class :

  • … only has public methods
  • … has both accessors (getter and setter) to all its attributes.
  • … has only very simple accessors.

… then it’s not a class, it’s a struct.

Here, to illustrate :

class MyClass
{
    int m_foo;
    int m_bar;

public:
    int addAll();
    int getFoo() const;
    void setFoo(int foo);
    int getBar() const;
    void setBar(int bar);
};

int MyClass::addAll()
{ 
    return m_foo + m_bar;
}
int MyClass::getFoo() const
{
    return m_foo;
}
void MyClass::setFoo(int foo)
{
    m_foo = foo;
}
int MyClass::getBar() const
{
    return m_bar;
}
void MyClass::setBar(int bar)
{
    m_bar = bar;
}

Is better written that way :

struct MyClass
{
    int foo;
    int bar;

    int addAll();
};

int MyClass::addAll()
{ 
    return foo + bar;
}

This is pretty much the same. You just withdraw a (useless) level of encapsulation for a more concise and more readable code.

The controversial part occur one the “useless” statement just above, because in a full-object mindset, no encapsulation is useless. In my opinion, this kind of structure don’t need encapsulation because it is just a data structure, and I don’t like when people overdo the concept of encapsulation.

Watch out, though, because this practice is only valid if all your attribute are in direct-access in both writing and reading. If one of our attribute need a specific accessor or you have read-only or write-only attributes, don’t use a struct (well, you can, but you need to seriously think about it).

Bad practice : Implementing undefined behavior

To say it short, an undefined behavior is a promise you make to the compiler that some behavior will never be implemented by your hand. Using that, the compiler will be able to make assumptions and optimize your code with those assumptions.

Go watch the talk of Piotr Padlewski : CppCon 2017: Piotr Padlewski ā€œUndefined Behaviour is awesome!ā€ – YouTube. It will teach you everything you need to know about UB.

Here is a non-exhaustive list of undefined behaviors. You need to know that list by heart in order to avoid unexpected undefined behavior in you codebase :

  • Calling main
  • Integer overflow
  • Buffer overflow
  • Using uninitialized values
  • Dereferencing nullptr
  • Forgetting the return statement
  • Naming variable starting with double underscore
  • Defining function in namespace std
  • Specializing non-user defined type in namespace std
  • Taking the address of a std function

So, it has to be said once and for all : do not ever rely on integer overflow to end a loop or for anything else. Because it does not mean what you think it means and one fateful day it will backfire hard.

Bad practice : Comparing signed and unsigned integer

When you compare signed and unsigned, an arithmetical conversion will occur that has a very good chance to distort the values, thus nullifying your comparison.

Use size_t when it’s relevant, and static_cast your variable if needed.

Bad practice : Trying to optimize the code as you write it

Yeah, that pill may be pretty hard to swallow. But here are two facts :

  • 80% of the time, the code you write doesn’t need to be optimized. Since most of your execution only occurs in 20% of your program (Pareto principle at work), the remaining 80% does not need to be optimized.
  • Optimization should not be a prior concern. You are to write your code, see the big picture, and optimize in consequence.

What is the most important is not how optimized is your program. The thing you should concern yourself about is whether your code is tidy, concise and maintainable. If it is, you can only come back later to optimize it.

Bad practice : Being too dumb

On the opposite, you shouldn’t under-optimize either.

You must know the specificities of the algorithms and the data structures in order to use the correct ones in your code. You need to understand some design patterns and be able to implement them so you don’t reinvent the wheel each time, you mustn’t be afraid to check the documentation before using a feature.

There is a good balance between coding without thinking and over-optimizing the code while you are writing it.

Bad practice : “If we need to do that later…”

I said it a few paragraphs above, but don’t plan on a hypothetical future. The only future you can be sure of is your most basic design. Your needs may change, your specs may change, what the client wants may change, anything beside the core design of your project may change. Sometimes it won’t, but often it will. Be sure to remember that.

When in doubt, be sure to ask yourself :

If I implement that later, will it cost more ?

Often, the answer is “no” or “not that much“. When so, leave the future to the future.

In the end…

Here you have a good start to write beautiful and maintainable code. If every dev on your project apply them, you will all benefit from it.

However, there are many many other basic bad practices I didn’t cover in this article, so the subject is not closed. Maybe I will publish a part 2 someday, maybe not.

Thanks for reading and see you next week!

Author: ChloƩ Lourseyre

Yet another pamphlet about inlining

Author: ChloƩ Lourseyre

Introduction

This week’s topic will be about the inline keyword.

This is a very old subject that, for me, has been settled for years. And everytime I re-enter the subject and document myself about, I end up with the same conclusions.

However, I very often read code that misuse this keyword, ending up in counterproductive and risky situations.

I will try here to summarize all you need to remember about inlining, giving pros, cons and situations to use it and to not use it.

Definition

I’ll start with the academical definition of inline :

The original intent of the inline keyword was to serve as an indicator to the optimizer that inline substitution of a function is preferred over function call, that is, instead of executing the function call CPU instruction to transfer control to the function body, a copy of the function body is executed without generating the call. This avoids overhead created by the function call (passing the arguments and retrieving the result) but it may result in a larger executable as the code for the function has to be repeated multiple times.
Since this meaning of the keyword inline is non-binding, compilers are free to use inline substitution for any function that's not marked inline, and are free to generate function calls to any function marked inline. Those optimization choices do not change the rules regarding multiple definitions and shared statics listed above.

Source : inline specifier – cppreference.com

What you need to retain from that are two things :

  • inline is used to avoid function overhead, replacing the call by the implementation at compile time.
  • It is only a hint given to the compiler. Some function declared inline may not really be inlined, and vice-versa.

With that in mind, let’s take a tour of the pros and the cons of this feature.

Pros

First of all, even if it’s a hint, the keyword may influence the compiler. It may not, but it also may. We can for instance think of the stupidest compiler that will just strictly respect the inline keyword, without trying to optimize himself. This is not against the standard (according to the C++11 standard Ā§12.1.5) and the keyword is useful in this case.

According to What is C++ inline functions – C++ Articles (cplusplus.com), the pros are :

  1. It speeds up your program by avoiding function calling overhead.
  2. It save overhead of variables push/pop on the stack, when function calling happens.
  3. It save overhead of return call from a function.
  4. It increases locality of reference by utilizing instruction cache.
  5. By marking it as inline, you can put a function definition in a header file (i.e. it can be included in multiple compilation unit, without the linker complaining).

Point number 1, 2 and 3 are overally the main benefits of this feature, and the original goal of the introduction of this keyword. Those who know a bit of assembly know that pushing a lot of parameters on the stack to call function can cost more instructions that the function holds.

Point number 4 seems to be a non-negligible side-benefit of this method, but since instruction cache is far from being my specialty, I will nt develop on this.

Point number 5 is pro only in certain specific cases, but a pro nonetheless.

Cons

According to What is C++ inline functions – C++ Articles (cplusplus.com), the cons are :

  1. It increases the executable size due to code expansion.
  2. C++ inlining is resolved at compile time. Which means if you change the code of the inlined function, you would need to recompile all the code using it to make sure it will be updated
  3. When used in a header, it makes your header file larger with information which users donā€™t care.
  4. As mentioned above it increases the executable size, which may cause thrashing in memory. More number of page fault bringing down your program performance.
  5. Sometimes not useful for example in embedded system where large executable size is not preferred at all due to memory constraints.

Points 1 and 4, which are unknown to a lot of developpers, are the main reason that function inlining can decrease performance. It is important to remember that when using this feature.

Point 2 can be a major inconvenient, depending on your project, but don’t occur so often in my experience.

Point 3 is, in my opinion, the main con of this feature. In order to have maintainable code you need to have to be clear and organized. Inlining is a huge code smells in that regard.

Point 5 is about specific projects, so I will not develop further. But keep in mind that if you have memory constraints, inlining may have consequences.

Conlusion : when to use the inline keyword ?

Avoiding function overhead is only usefull if you are in a performance critical part of your code.

You probably already know the Pareto’s law : “80% of the execution happens in 20% of the code”. This means that the program spends most of it’s time in bottlenecks. Thus, if you inline code that is not within a bottleneck, this will have little to no effect on your program performance, while increasing its size.

What urged me to write this article is that during my coder’s life, I saw many many codebase polluted by useless inlines. I can safely say that more than 95% of the inlining I saw in industrial projects was used in non-critical code.

There is absolutly no need in decreasing the readability of the code and increasing the executable size for that end.

Here is my advice : don’t use inline unless you are 100% sure it is called inside a bottleneck.

This is the only way to be both efficient and clean.

Another type of inlining

I will end this article by adding a word about a special case of “inlining”.

If you are someone who likes to write things like this :

inline void setValue(int i) { m_value = i; }

and by that I mean, the prototype and the implementation all on one line, please understand that this prevent many debuggers from doing their jobs properly.

For instance, in VisualStudio, if you put a breakpoint inside this setValue method, when it hits the debugger won’t be able to give you the value of m_value.

So please, I’m begging you, stop doing that. It won’t cost you much to add a newline.

Thank you, and see you next week!

Author: ChloƩ Lourseyre

Passing an enum by parameter

Author: ChloƩ Lourseyre

Let’s say you have a function you have to call using two parameters :

  • The first parameter is a configuration option symbolized by an enum. Like the “mode of use” of your function.
  • The second parameter is a true numeral parameter.

Let’s use the following example to represent that :

#include <iostream>

// Enum describing the mode used in the following function
enum class ChangeMode
{
    Before,
    After
};

// Function that squares a value and increases it (wether before or after), then prints the result
void increase_and_square(const ChangeMode& m, int v)
{
    if (m == ChangeMode::Before)
        ++v;
    
    v = v*v;
    
    if (m == ChangeMode::After)
        ++v;

    std::cout << v << std::endl; 
}

// main function
int main()
{
    const int a = 42;
    increase_and_square(ChangeMode::Before, a);
    increase_and_square(ChangeMode::After, a);
}

In this example, we perform slightly different operation depending on the “mode” used. This is a fairly common behavior that can occur in may different forms.

However, implemented as it is there is not the most optimized way to do this. A best way to obtain the same result is to use the ChangeMode as a template instead of a plain parameter.

Like this :

#include <iostream>

// Enum describing the mode used in the following function
enum class ChangeMode
{
    Before,
    After
};

// Function that squares a value and increases it (wether before or after), then prints the result
template<ChangeMode m>
void increase_and_square(int v)
{
    if (m == ChangeMode::Before)
        ++v;
    
    v = v*v;
    
    if (m == ChangeMode::After)
        ++v;

    std::cout << v << std::endl; 
}

// main function
int main()
{
    const int a = 42;
    increase_and_square<ChangeMode::Before>(a);
    increase_and_square<ChangeMode::After>(a);
}

Impementing the function like is actually better in every way :

  • Operations done at compile time : of course, and as the main advantage of using templates, we evaluate more expressions a compile time here, saving run time.
  • Compiler optimization : since the compiler will be able to evaluate more things at compile time, it will be able to optimize the code, effectively discarding the if statements.
  • Executable size : more impressive, the executable will be smaller with the templated version. This is so because the fact that we discard the if statement actually greatly reduce the size of the functions.

To illustrate this, here is the template instanciation the compiler generates :

void increase_and_square<ChangeMode::Before>(int v)
{
    ++v;
    v = v*v;
    std::cout << v << std::endl; 
}

void increase_and_square<ChangeMode::After>(int v)
{
    v = v*v;
    ++v;
    std::cout << v << std::endl; 
}

These are way simpler functions that the big bulky one above.

If you are not convinced, here is the number of assembly instructions the compiler generates (I used Compiler Explorer (godbolt.org) with clang as compiler and --std=c++20 -O3 as compiler options).

Parameter

123

Template

76

The template version is clearly better, faster, prettier.

Perk : double default values

Using the template version of this code also provides another perk : the ability to give a default value to your mode and to your parameter.

Since default values are decorrelated for templates and parameters, you can write this :

#include <iostream>

// Enum describing the mode used in the following function
enum class ChangeMode
{
    Before,
    After
};

// Function that squares a value and increases it (wether before or after), then prints the result
template<ChangeMode m=ChangeMode::Before>
void increase_and_square(int v = 2)
{
    if (m == ChangeMode::Before)
        ++v;
    
    v = v*v;
    
    if (m == ChangeMode::After)
        ++v;

    std::cout << v << std::endl; 
}

int main()
{
    const int a = 42;
    increase_and_square(a);
    increase_and_square<ChangeMode::After>();
    increase_and_square();
}

This is interesting because the mode and the parameter actually have different semantic meanings, thus it is only logical that they have separate behavior.

Limitations

Why does this work ? Because the “mode” we template is actually an enum with very few values.

If you happen to use an bigger enum (with 5+ different values) or other types, the template version will be way worse than the parameter version.

In general, you will have no use doing what we saw in this article, but in the very specific case you have an enum that describes a “mode of use” of your function and has 2 or 3 possible values, take time to consider using it as template.

Keep in mind that this model, if seducing, is very specific and will not apply in your day-to-day coding.

Semantic

I will conclude this article by talking a bit about semantics.

What we achieved here could be seen as an overload of the increase_and_square() function. Indeed, we did several implementations of the same function (well, the template did it for us) that has a similar-yet-different behavior. This is exactly what overloading is about.

This is also why I described the enum as a “mode” : it describes how the function must work, and is more that than a real parameter.

Thanks for your attention and see you next week!

Author: ChloƩ Lourseyre

About &= and |=

Author: ChloƩ Lourseyre

I often happen to see, on pretty old projects, the operators &= and |= used to update a boolean indicating success that is returned along successive function calls. As in the following example :

bool success = true;
success &= DoOneThing();
success &= DoOneOtherThing();
success &= DoALastThing();
if (success)
    std::cout << "Success !" << std::endl;

This way of writting is more concise than the usual :

bool success = true;
success = success && DoOneThing();
success = success && DoOneOtherThing();
success = success && DoALastThing();
if (success)
    std::cout << "Success !" << std::endl;

But you should be cautious, because behind the operators &= and |= hide a few subtelties that one should be aware of.

Definition of the operators &= and |=

First, let’s see precise definition of &= and |=. In this section, I’ll only use &= as an example, but the behavious of |= is pretty much the same.

&= is an arithmetic binary operator, which permforms a binary AND and its assignation. In other terms, writting this :

v1 &= v2;

is equivalent to this :

v1 = v1 & v2;

except that v1 is only evaluated once.

For more insight about this, read the C++11 standard section 5.17 Assignment and compound assignment operators or go to https://en.cppreference.com/w/cpp/language/operator_arithmetic

What we call “arithmetic binary operators” (which use the symbols &, |, ^, << and >>) are operators that perform bit-to-bit operations.

For instance :

int a = 0b110;
int b = 0b011;
int c = a & b; // AND - 010
int d = a | b; // OR  - 111
int e = a ^ b; // XOR - 101

Writting a &= b; is thus performing a bit-to-bit AND operation on a and b, and assigns the result to a.

Differences between &= and &&, |= and ||

The operators && and || are, as for them, logical operators, as opposed to &= and |= who are arithmetic operators.

The use of &= and |= in a logical context is prone to diverge from what we could expect them to do.

Here are two example to illustrate that.

Example 1

#include <iostream>

bool foo()
{
    std::cout << "call foo()" << std::endl;
    return true;
}

int main() {
    bool c = true;
    std::cout << "Using |=" << std::endl;
    c |= foo();
    std::cout << "Using = and ||" << std::endl;
    c = c || foo();
    std::cout << "End" << std::endl;
    return 0;
}

The function foo() always returns true, as long as writing on the standard output to indicate it’s been called.

In the main() function, we create a bool c, initialized true, on which we will perform the arithmetic binary operator |= and the logical operator ||.

Here is the standard output :

Using |=
call foo()
Using = and ||
End

We can plainly see that in the |= case, foo() is called whereas it is not in the || case.

This is simply due to the fact that, in C++, logical operators are lazy. This means that if the right-hand-side of the operation can not change its result after evaluating the left-hand-side, then it won’t be evaluated.

Here, because c is already true in the expression c || foo(), no matter the value of foo() the result of the operation will always be true.

In the case of |=, it is a bit different. |= is not a logical operator, it does not reason in terms of true or false, but it performs arithmetic operations on integers. Thus, it needs to evaluate each side of the operation before evaluating the result. With arithmetic operations, both side are always evaluated.

Whether you wish the right-hand-side to be evaluated depends on the context. However, keep in mind that when C++ developpers see logical-like operations, they expect it to be lazy.

Example 2

The following example, though quite uncommon in practice, can lead to errors that are difficult to investigate.

#include <iostream>

int main() {
    int c1 = true;
    int c2 = 0b10;

    if (c1)
        std::cout << "c1 is true" <<std::endl;
    else
        std::cout << "c1 is false" <<std::endl;

    if (c2)
        std::cout << "c2 is true" <<std::endl;
    else
        std::cout << "c2 is false" <<std::endl;

    if (c1&&c2)
        std::cout << "c1&&c2 is true" <<std::endl;
    else
        std::cout << "c1&&c2 is false" <<std::endl;

    c1 &= c2;

    if (c1)
        std::cout << "c1&=c2 -> c1 is true" <<std::endl;
    else
        std::cout << "c1&=c2 -> c1 is false" <<std::endl;

    return 0;
}

Here, two variables are created : c1 which is initialized to true, and c2, which is initialized to 0b10.

Following four blocs performing logical evaluations :

  • First we logically evaluate c1.
  • Then, we similarly evaluate c2.
  • Then we evaluate the logical operation c1 && c2.
  • Finaly, we realise the arithmetic binary operation c1 &= c2 just before evaluating c1 again.

Here is the standard output of this code :

c1 is true
c2 is true
c1&&c2 is true
c1&=c2 -> c1 is false

Let’s see in details how this works :

First of all, c1 is considered true. This is expected because it is explicitly initiliazed with true.

Secondly, c2 is also considered true. This is so because, in C++, any non-null integer evaluates to true.

Thirdly, c1 && c2 is evaluated to true. Indeed, because c1 and c2 and individually true, performing the AND operation on them is logically true.

Fourthly, we perform c1 &= c2;. By doing so, we actually perform c1 & c2 and affect the result to c1.

However, according to the standard, true is equal to 1 when promoted to integer. Thus, c1 & c2 is equivalent to 0b01 & 0b10. The result to this operation really is 0b00, the bit-to-bit AND operation is false for every bit.

The 0 value being evaluated to false in a logical expression, c1 is, after all, false.

You won’t see this happen very often in live code, but there is plenty of situations, especially in legacy code, when an integer value that is not 1 is returned as if it was a true boolean.

Conclusion

The use of &= and |= will do what we expect in 99% of the case. But in the remaining 1%, you’ll have major bugs difficult to investigate.

Moreover, I’d like to pinpoint a semantic problem here. The fact that we ue an arithmetic operation instead of a logical one mislead the reader and forces them to do an additional effort to pull this straight. In addition to that, it may prevent the compiler to perform optimization.

Writting a = a && b; instead of a &= b; is not much an effort, with only a few additional characters, but it will protect you from bugs and hold better semantics.

Thank you for your attention and meeting you next week !

NB : The example were done with clang and the compiler options --std=c++20 -O3

Author: ChloƩ Lourseyre