intermediate

Dive into C++11 (#3)—Automatic lifetime, pointers, dynamic allocation

[Note: Automatic lifetime is indeed the right default -- correct and efficient. When you need to use the heap, however, note that you should now use unique_ptr (or if necessary shared_ptr via make_shared) instead of explicit new and delete. -- Ed.]

 

Hello again, I’m Vittorio Romeo, a computer science student, hobbyist game developer and C++ enthusiast.

I’ve uploaded the third episode of “Dive into C++11” on my YouTube channel.

In this episode we'll take a break from game development to delve into C and C++'s memory and lifetime management.

We'll talk about automatic variable lifetime, pointers in general and dynamic memory allocation.

The intended audience for this tutorial/screencast are people who have some experience with C++ in general, and who watched the previous episodes. This episode may be very interesting for those with experience with C++ who want to learn more about variable lifetime and memory management.

I greatly appreciate comments and criticism, and ideas for future videos/tutorials.

Feel free to fork/analyze the source code at: https://github.com/SuperV1234/Tutorials

You can find the previous episodes here:

Data Locality -- Bob Nystrom

data-locality.PNGA nice refresher on data locality, and coding techniques to improve it for substantial performance gains.

Data Locality

by Bob Nystrom

From the article:

Sure, we can process data faster than ever, but we can’t get that data faster. ...

When I started working on this chapter, I spent some time putting together little game-like programs that would trigger best case and worst case cache usage. I wanted benchmarks that would thrash the cache so I could see first-hand how much bloodshed it causes.

When I got some stuff working, I was surprised. I knew it was a big deal, but there’s nothing quite like seeing it with your own eyes. I wrote two programs that did the exact same computation. The only difference was how many cache misses they caused. The slow one was fifty times slower than the other.

Type Erasure, Part 3 -- Andrzej Krzemieński

In part 3, Andrzej turns to some practical use cases for type erasure.

Type Erasure, Part 3

by Andrzej Krzemieński

From the article:

Who needs type erasure?

... Here is what I learned from my experience. There are a couple of trade-offs to be made when using or not type erasure: run-time efficiency vs compilation time, run-time efficiency vs binary size. The choice is not obvious. Even in programs that need to be fast, not every part of the program needs to be fast. Some portions, like the interaction with the user, can be slow, and for these parts you can apply different trade-offs.

Type Erasure, Part 2 -- Andrzej Krzemieński

In part 1, Andrzej explained what "type erasure" is all about. But how do you create custom type-erased interface?

Type Erasure, Part 2

by Andrzej Krzemieński

From the article:

While there are many ways to erase a type, I will use name type erasure to denote the usage of std::function-like value-semantic interface. This convention appears to be widely accepted in C++ community.

... Using std::function is easy, but this is because someöne has made an effort to implement it for us. So let’s try to see how much effort it is to write our own type-erased interface. We will be using countdown counters: something that (1) can be decremented and (2) tested if the count reached zero.

The Cost of Dynamic (Virtual Calls) vs. Static (CRTP) Dispatch in C++ -- Eli Bendersky

eli-bendersky.PNGA nice dive into performance costs on at least one compiler, and on the difficulties of doing meaningful performance measurements on modern hardware. Be sure to read the short comment thread too.

The Cost of Dynamic (Virtual Calls) vs. Static (CRTP) Dispatch in C++

by Eli Bendersky

From the article:

A couple of years ago I wrote an article about the Curiously Recurring Template Pattern in C++, focusing on the motivation behind it and how to implement it.

That article mentioned runtime performance as the main reason for employing CRTP instead of the more traditional runtime polymorphism (dispatch via virtual functions). While some rationale for the cost of virtual calls was given, I didn’t go too deep into it. Today I want to fix that by carefully analyzing the performance of virtual calls as opposed to the static calls made possible by CRTP.

Mandatory precaution about benchmarks

Benchmarking in 2013 is really hard. ...

Using STL Vectors, and Efficient Vectors of Vectors -- Thomas Young

thomas-young.jpegThese are also the first two articles in a new blog by the creator of the PathEngine SDK.

Note: One or two of the points can be controversial, but the content is interesting and informative especially as an experience report.

Using STL Vectors

Efficient Vectors of Vectors

by Thomas Young

From the articles:

The stuff we do with vectors can be broadly categorised into two main use cases:

  • the construction of (potentially complex) preprocess objects, and
  • run-time buffers for queries, where buffer size requirements are fundamentally dynamic in nature

Preprocess objects include things like the pathfinding visibility graph. These objects can take time to build, but this is something that can be done by the game content pipeline, with preprocess data saved and loaded back from persistence by the game runtime.

The Curious Case of the Recurring Template Pattern -- K-Ballo

Do you remember CRTP? No? Then definitely read about it here:

The Curious Case of the Recurring Template Pattern

by K-ballo

Inheritance is a handy tool to simplify design and avoi code duplication. However, good old fashioned inheritance is not always the right tool for the job. What if a base class could know, at compile time, who derives from it? Enter the curiously recurring template pattern (CRTP)...

Quick Q: A lambda's return type can be deduced, so why can't a function's? -- StackOverflow

Quick A: It can, in C++14. In fact, this C++14 feature supported today in current versions of GCC and Clang with -std-c++1y and in the Visual C++ November 2013 CTP.

On SO:

A lambda's return type can be deduced by the return value, so why can't a function's?

#include <iostream>

int main(){

    auto lambda = [] {
        return 7;
    };

    std::cout << lambda() << '\n';

}

This program compiles and prints 7.
The return type of the lambda is deduced to the integer type based on the return value of 7.

Why isn't this possible with ordinary functions?

#include <iostream>

auto function(){
    return 42;
}

int main(){

    std::cout << function() << '\n';
}

error: ‘function’ function uses ‘auto’ type specifier without trailing return type

Say hello to wxWidgets3.0

A few weeks ago wxWidgets3.0 was released, now it's time to take a look at it:

Say hello to wxWidgets3.0

From the Article

I remember the times, when wxWidgets 3.0 was already talked about, several years ago. Now, its been published in November, though I have to take a look at it. I've been using wxWidgets for years, but moved on to Qt for my own projects. So, lets have a look at wxWidgets 3.0...

Dive into C++11 (#2) -- Frametime/FPS, constexpr, uniform initialization, and more

Hello again, I’m Vittorio Romeo, a computer science student, hobbyist game developer and C++ enthusiast.

I've uploaded the second episode of "Dive into C++11" on my YouTube channel. You can find the first episode here.

You can find the complete playlist here.

In this episode we will learn more about two previously mentioned new awesome C++11 features: "constexpr" and "uniform initialization syntax".

Most importantly, we will also deal with a very big issue that every game developer must face: FPS/frametime, and how to avoid the game from behaving differently on slower/faster machines.

In addition, we'll also briefly learn about "const-correctness" and using the "noexcept" keyword.

We will analyze the "time-slice" method to allow the game to run smoothly and consistently on every machine.

In the last code segment, we will also "refactor" our code by creating a `Game` class, making our source much easier to read and maintain.

I greatly appreciate comments and criticism, and ideas for future videos/tutorials.

Feel free to fork the game's source code at: https://github.com/SuperV1234/Tutorials