June 8-13, Brno, Czechia
June 17-20, Folkestone, UK
September 12-18, Aurora, CO, USA
November 16-21, Búzios, Rio De Janeiro, Brazil
November 26-28, Berlin, Germany
By Blog Staff | Dec 30, 2013 11:50 AM | Tags: intermediate
Quick A: Oh, yeah.
See the nice three-paragaph "highlights" answer to the question:
Does alignment really matter for performance in C++11?
There is an advice in Stroustrup's book to order the members in a struct beginning from the biggest to the smallest. But I wonder if someone has made measurements to actually see if this makes any difference, and if it is worth it to think about when writing code.
By Bjarne Stroustrup | Dec 27, 2013 03:40 AM | Tags: intermediate c++11 basics
[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.
By Meeting C++ | Dec 26, 2013 01:53 PM | Tags: intermediate c++14 c++11 boost basics
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 (
nullptrf.e.), the semantics and usage of pointers in C++ has changed over the last years.
By Vittorio Romeo | Dec 19, 2013 01:36 PM | Tags: intermediate
[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:
By Blog Staff | Dec 17, 2013 03:10 AM | Tags: intermediate
A 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.
By Blog Staff | Dec 16, 2013 01:58 AM | Tags: intermediate
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.
By Blog Staff | Dec 10, 2013 09:21 AM | Tags: intermediate
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.
By Blog Staff | Dec 9, 2013 12:14 PM | Tags: intermediate
A 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. ...
By Blog Staff | Dec 6, 2013 12:36 PM | Tags: intermediate basics
These 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.
By Blog Staff | Dec 6, 2013 10:37 AM | Tags: intermediate
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)...
