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

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

Comments (3)

1 0

Claude Adrian, CodeAngry said on Dec 3, 2013 05:11 AM:

At minute 9:00 you talk about initializing auto with POD types. That should not happen! auto is meant, IMO, mostly for function returns values or for already existing variables. It's actually a solution for very long and convoluted data types. So:



int x(1);

auto y(x);

auto z(function());

But don't encourage anyone (especially beginners) to, just because they can:



auto x(1);

Maybe they want unsigned, maybe they want a float or a 64bit int. This kind of POD type values should always be clearly defined by type. I'd even enforce this in the compiler, like don't auto numbers.

As C++ devs, we are used to writing more code and that's OK. This should not be a place to get fancy and save on keystrokes.

PS: I learned the hard way that letting the compiler make the simple/lazy choices for you can cause some headache.

0 1

LBEaston said on Dec 3, 2013 11:40 PM:

@Claude Adrian
I'm agree that for literal numbers auto should not be used in that way.
I think that

auto x = int{1};

is the better alternative.

2 0

Zenju said on Dec 17, 2013 09:32 AM:

Or another one. Why not simply:
dectltype(int{42}) x{2 / 2};

Jesus; why is it that when some people try to reinvent a better wheel they end up with a square?

Share this Article

Add a Comment

Comments (3)