June 16-21, Sofia, Bulgaria
September 13-19, Aurora, CO, USA
October 25, Pavia, Italy
November 6-8, Berlin, Germany
November 16-21, Kona, HI, USA
By Blog Staff | Jun 13, 2013 04:33 PM | Tags: intermediate
From SO:
When are implicit move constructors not good enough?
Should I treat it like destructors and copy constructors, where it's generally only necessary if I manage my own memory?
Is the implicit move constructor good enough in this (very contrived) scenario: ...
By Blog Staff | Jun 13, 2013 04:28 PM | Tags: intermediate
ARK's latest, hot off the press:
When Is It Safe to Move an Object Instead of Copying It?
by Andrew Koenig
From the article:
Last week, I introduced the idea of moving objects, and explained that moving an object is usually better than copying it if the original is not going to be used again. Now I'd like to explain how the compiler can figure out during compilation when to move objects instead of copying them.
As is so often the case with such problems, the obvious solution is wrong. Consider this code fragment: ...
By Blog Staff | Jun 11, 2013 09:38 AM | Tags: intermediate advanced
The two latest C++ lectures by Stephan T. Lavavej, the eponymous STL, are now available:
Core C++, 8 of n
In part 8, STL digs into the do-while loop, casts, one definition rule (ODR), and his variadic template array sorter. There is a lot of information in this episode, so get comfortable, tune in, and learn.
Core C++, 9 of n
In part 9, STL digs into lambdas and other expressions. Lambdas are very useful and you've no doubt been enjoying them in your modern C++ programming. As you can imagine, STL will go deep and teach you things about lambdas that you may not know. You'll also learn a lot about order of precedence and associativity for expressions in only the way Stephan can teach you (thorough treatment). Tune in.
By marshall | Jun 10, 2013 04:09 PM | Tags: intermediate c++now boostcon
The keynote addresses for C++Now 2013 are now available.
We are confronted today with the increasing complexity of our C++ software systems. To manage this complexity and build larger applications and systems, C++ strives to form emergent structures (often found in nature, such as snowflakes' symmetrical structures), where simple patterns combine to form a remarkably complex and powerful system. These structures provide both a means to limit the complexity of each component and the essential economies of scale we rely on when developing software.
From handheld devices to warehouse-sized data centers, motivated by smaller devices and increased concerns over power consumption, we are relying upon C++ to deliver these complex systems with unmatched efficiency. Our optimizing compilers today are more important than ever before and are utterly opaque to most practicing programmers. Compounding matters, the very emergent structures which allow C++ systems to scale for humans often provide unique and unsolved challenges to optimization.
In this talk, I will start with a brief overview of how modern optimizing compilers work with C++ code at a very high level. I will then walk through the specific structures and patterns of C++ code, which are at the core of forming emergent structures out of simple, elegant elements. I will also address how these interactions can be effectively modeled and analyzed by a compiler to produce efficient final programs. All of this will be illustrated by a collection of real world case studies, which are broadly applicable and show up throughout modern C++ code bases. My goal is to give a framework for understanding these interactions both in the C++ code and the optimizing compiler, so that programmers are aware of the implications posed by these patterns. Finally, I will introduce a set of principles and techniques for designing and implementing C++ programs and libraries to specifically clear the way for modern optimizers while retaining the simplicity of each component and the power of the combined whole.
We'll discuss language life cycles, particularly as they apply to C++, from a peek at some of the very early ideas and technology behind C++ to a proposal for the next step: yet another paradigm shift, not a evolution or revolution but simply a synchronizing of meta4layers — using fertilization of the multi-cell organism as an isomorph.
By Blog Staff | Jun 7, 2013 05:42 PM | Tags: intermediate basics
The solution to the latest GotW problem is now available:
GotW #92 Solution: Auto Variables, Part 1 (updated for C++11/14)
by Herb Sutter
From the article:
When you’re new to
auto, the key thing to remember is that you really are declaring your own new local variable. That is, “what’s on the left” is my new variable, and “what’s on the right” is just its initial value:auto my_new_variable = its_initial_value;You want your new variable to be just like some existing variable or expression over there, and be initialized from it, but that only means that you want the same basic type, not necessarily that other variable’s own personal secondary attributes such as top-level
const-ness and reference-ness which are per-variable. For example, just because he’sconstdoesn’t mean you’reconst, and vice versa.It’s kind of like being identical twins: Andy may be genetically just like his brother Bobby and is part of the same family, but he’s not the same person; he’s a distinct person and can make his own choice of clothes and/or jewelry, go to be seen on the scene in different parts of town, and so forth. So your new variable will be just like that other one and be part of the same type family, but it’s not the same variable; it’s a distinct variable with its own choice of whether it wants to be dressed with
constand/or a reference, may be visible to different threads, and so forth.Remembering this will let us easily answer the rest of our questions...
By Blog Staff | Jun 7, 2013 05:33 AM | Tags: intermediate
A belated link to Andrzej's recent article:
Empty list initialization
by Andrzej Krzemieński
From the article:
My conclusion from the above story is this piece of advice. When you provide an initializer-list constructor for your class, make sure that you also provide a default constructor with the same semantics as though you were initializing with a zero-size
initializer_list.
By Blog Staff | Jun 5, 2013 05:37 PM | Tags: intermediate
The solution to the latest GotW problem is now available:
GotW #91 Solution: Smart Pointer Parameters (updated for C++11/14)
by Herb Sutter
From the article:
Guideline: Don’t pass a smart pointer as a function parameter unless you want to use or manipulate the smart pointer itself, such as to share or transfer ownership.
Guideline: Prefer passing objects by value,*, or&, not by smart pointer.If you’re saying, “hey, aren’t raw pointers evil?”, that’s excellent, because we’ll address that next...
By Blog Staff | Jun 5, 2013 02:45 PM | Tags: intermediate
Good advice from the designer of the new std::optional<T> on how to design modern C++ classes to follow GotW #1's advice to avoid writing initializer_list constructors that force callers to resort to () instead of {} to disambiguate.
Intuitive Interface -- Part I
by Andrzej Krzemieński
From the article:
Let’s start with the popular C++(11) “uniform initialization” gotcha. Changing braces to parentheses in object initialization may change the semantics of the initialization:
std::vector<int> v1{5, 6}; // 2 elems: {5, 6} std::vector<int> v2(5, 6); // 5 elems: {6, 6, 6, 6, 6}For instance, it is described in Problem 1 of the newly revisited “Guru of The Week” series by Herb Sutter.
When seeing such an example, one might conclude that the new rules for object initialization are very confusing or error-prone. But to me it looks like the problem here lies in how class template
std::vectorhas been defined in C++03...
By Blog Staff | Jun 4, 2013 04:46 PM | Tags: intermediate
On Friday, June 14, Scott Meyers will be giving a talk open to the public at the Oslo C++ Users Group.
From Scott's announcement:
Lambdas vs. std::bind in C++11 and C++14
Scott Meyers
C++ developers have long had a need to bind functions and arguments together for a later call. This is what makes it possible to invoke member functions on objects inside STL algorithms. The same technology can be used to create custom callback functions and to adapt function interfaces to different calling contexts.
In C++98, such binding was accomplished via
std::bind1standstd::bind2nd. TR1 addedstd::tr1::bind, which was promoted tostd::bindin C++11. But C++11 also introduced lambda expressions, and they’re slated to become even more powerful in C++14. That means that there are now two mechanisms in C++ for binding functions to arguments for later calls:std::bindand lambda expressions. In this talk, Scott examines the pros and cons of each approach, comparing them in terms of expressiveness, clarity, and efficiency, and he comes to the conclusion that one should almost always be used instead of the other. But which one?
This presentation assumes a basic familiarity with
std::bindand C++11 lambda expressions.
By Blog Staff | Jun 3, 2013 12:47 PM | Tags: intermediate
Quick A: No.
Some authors wrote "Consider doing this" in C++98. The answer is now a definite "No" because it prevents move from returned values.
Isn't the const modifier here unnecessary?
The "Effective C++" Item 3 says "Use
constwhenever possible", and it gives an example like:
const Rational operator*(const Rational& lhs, const Rational& rhs);to prevent clients from being able to commit atrocities like this:
Rational a, b, c; ... (a * b) = c; // invoke operator= on the result of a*b!But isn't the non-reference return value of functions allready a rvalue? So why bother doing this?