basics

A shared view of C++ (or, Around the C++ world in 180 pages)

[Note: There has long been “one short and reasonably complete book you can assume everyone has read” for C -- K&R 2nd Edition (274 pages). But what is the “one short and reasonably complete book you can assume everyone has read” for C++? Does a single short one even exist, and is it possible for one to exist? This post by Bjarne Stroustrup addresses that important question, with what we feel is the year's most important book on C++ -- more important than even the C++11-updated The C++ Programming Language, 4th Ed., also by Stroustrup.

The "(or, Around the C++ world in 180 pages)" alternate title for this blog post is our editorial suggestion, with apologies to both Stroustrup and Jules Verne. We believe this is quite appropriate for Stroustrup's year-end gift to the C++ community. Enjoy. --Ed.]

 

For a graduate course in software design, I needed a few introductory lectures to “refresh” my students’ understanding of C++. For The C++ Programming Language (Fourth Edition), I wrote introductory chapters (about 80 pages) to give the reader an overview of C++ before diving into the details. At the suggestion of Herb Sutter, I posted drafts of those four Tour of C++ chapters on isocpp.org, and at the suggestion of my Addison Wesley editor, Peter Gordon, I expanded these chapters to provide a comprehensive overview of and introduction to C++ (for people who are already programmers, not complete novices):

A Tour of C++

by Bjarne Stroustrup

Addison Wesley, ISBN 978-0321958310, 2013

In 180 pages, it covers the major C++11 features and techniques plus most of the standard library. 180 pages is something most programmers can find the time to read. The tour (Tour++) benefited greatly from use and comments from many readers.

It gradually dawned on me that I just might have produced a solution to a decades-old problem for C++:

What is the basic knowledge that we should be able to assume from a competent C++ programmer?

Competent C programmers can be assumed to know roughly what is covered by K&R. Conversely, if they don’t -- or haven’t even heard of K&R -- it is a good guess that they can’t be relied on to contribute viable C code. I find that I cannot make an equivalent statement about C++ programmers. Once upon a time, knowing TC++PL (1st edition) served as a shared base, but that was a long time ago and C++ has improved immensely since 1985. These days, there are functioning C++ programmers who have learned all they know from the Qt documentation, from boost.org, from Scott Meyers’ many books, from some of my books and papers, from some of Herb Sutter’s books, etc., but don’t know more than one of these sources. Their ideas of what C++ is are disjoint and incompatible. Many more programmers appear to base their understanding of C++ on some ancient, outdated, and usually poor college textbook plus what they learn from on-line documentation and following some C++ Q&A site. But you don’t become a good C++ programmer just by knowing only the C++ syntax and a multitude of library classes and functions. Similarly, being able to answer tricky “interview-style” questions about the ISO standard doesn’t make you a good C++ Programmer.

We -- the huge and diverse C++ communities -- do not share a body of basic understanding. This is bad; very bad! We don’t have a shared view of what good C++ code is and we don’t communicate effectively. I find -- from web posting, from academic papers, from my email, and more -- that huge chunks of the last 20 years of progress in design technique, programming technique, and language support remain unknown and unused by many “C++ programmers.” What a waste! More specifically, what a waste of energy as programmers suffer from outdated parochial views in their current work today! Conversely, what an opportunity for improvement!

Many have tried to address parts of this problem. The sources I mentioned above are not bad, but they are not shared and few are comprehensive. I can and do recommend them often. Further, I recommend the many superb talks from the “Going Native” 2012 and 2013 conferences (freely available on the Web) as well as talks recorded at Google, ACCU, and others. It is not volume of material we lack. On the contrary, it is quite easy to drown in information about C++. Few practicing programmers can keep up with all the quality information being produced. Worse, the quality information is often drowned by the constant deluge of poor, outdated, and often wrong information provided on the web (and elsewhere).

As the risk of being seen as a blatant self-promoter, I would like to recommend A Tour of C++. [We wholeheartedly support this recommendation. --Ed.] For a technical book, it is a quick read, and it is not a waste of time: I have never met a programmer of any experience level who didn’t learn something from reading it. If everyone read it, the C++ community would again -- after something like 25 years -- have a common conceptual framework and vocabulary. Read it! You might even like it.

Thoughts on C++'s future and the pointer

I've written down some thoughts on the future of C++ and the pointer:

C++ future and the pointer

From the Article:

The last weeks after Meeting C++ 2013 I've been thinking a lot about C++, and also a little bit about pointers. While C++11 brought only little changes for pointers (nullptr f.e.), the semantics and usage of pointers in C++ has changed over the last years.

Nugget: C++1y Automatic Type Deduction -- Tony DaSilva

A short nugget by Tony DaSilva:

C++1y Automatic Type Deduction

by Tony DaSilva

From the article:

In addition to this convenient usage, employing auto in conjunction with the new (and initially weird) function-trailing-return-type syntax is useful for defining function templates that manipulate multiple parameterized types (see the third entry in the list of function definitions below).

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.

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...

Quick Q: Why have move semantics? -- StackOverflow

Quick A: Because value semantics are clean and naturally (exception-)safe, and avoid the brittleness of pre-C++11 workarounds that resort to owning raw pointers.

As often happens, the question contains the answer...

Why have move semantics?

... Can't the client already take advantage of pointers to do everything move semantics gives us? If so, then what is the purpose of move semantics?

Move semantics:

std::string f()
{
    std::string s("some long string");
    return s;
}
int main()
{
    // super-fast pointer swap!
    std::string a = f();
    return 0;
}

Pointers:

std::string *f()
{
    std::string *s = new std::string("some long string");
    return s;
}

int main()
{
    // still super-fast pointer swap!
    std::string *a = f();
    delete a;
    return 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

Quick Q: Why write "5 == myValue" instead of "myvalue == 5"? -- StackOverflow

Quick A: Because it catches most cases where you accidentally wrote = instead of ==.

From SO:

Reason for using '5 == myValue' in conditionals

I've come across some code that flips how a condition is checked and was wondering why this would be done aside from a weird personal quirk. I've never seen any text books use it nor have I seen any sample code done this way.

// why do it this way?
if (5 == myValue)
{
    // do something
}

// instead of:
if (myValue == 5)
{
    // do something
}

I've only seen this way for == operand but not for any other operands.