intermediate

CppCon 2015 Writing Good C++14… By Default—Herb Sutter

Have you registered for CppCon 2016 in September? Don’t delay – Early Bird registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2015 for you to enjoy. Here is today’s feature:

Writing Good C++14... By Default

by Herb Sutter

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

Modern C++ is clean, safe, and fast. It continues to deliver better and simpler features than were previously available. How can we help most C++ programmers get the improved features by default, so that our code is better by upgrading to take full advantage of modern C++?

This talk continues from Bjarne Stroustrup’s Monday keynote to describe how the open C++ core guidelines project is the cornerstone of a broader effort to promote modern C++. Using the same cross-platform effort Stroustrup described, this talk shows how to enable programmers write production-quality C++ code that is, among other benefits, type-safe and memory-safe by default – free of most classes of type errors, bounds errors, and leak/dangling errors – and still exemplary, efficient, and fully modern C++.

Background reading: Bjarne Stroustrup’s 2005 “SELL” paper, “A rationale for semantically enhanced library languages," is important background for this talk.

CppCon 2015 Writing Good C++14—Bjarne Stroustrup

Have you registered for CppCon 2016 in September? Don’t delay – Early Bird registration is open now.

While we wait for this year’s event, we’re featuring videos of some of the 100+ talks from CppCon 2015 for you to enjoy. Here is today’s feature:

Writing Good C++14

by Bjarne Stroustrup

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

How do we use C++14 to make our code better, rather than just different? How do we do so on a grand scale, rather than just for exceptional programmers? We need guidelines to help us progress from older styles, such as “C with Classes”, C, “pure OO”, etc. We need articulated rules to save us from each having to discover them for ourselves. Ideally, they should be machine-checkable, yet adjustable to serve specific needs.

In this talk, I describe a style of guidelines that can be deployed to help most C++ programmers. There could not be a single complete set of rules for everybody, but we are developing a set of rules for most C++ use. This core can be augmented with rules for specific application domains such as embedded systems and systems with stringent security requirements. The rules are prescriptive rather than merely sets of prohibitions, and about much more than code layout. I describe what the rules currently cover (e.g., interfaces, functions, resource management, and pointers). I describe tools and a few simple classes that can be used to support the guidelines.

The core guidelines and a guideline support library reference implementation will be open source projects freely available on all major platforms (initially, GCC, Clang, and Microsoft).

Quick Q: What are rvalues, lvalues, xvalues, glvalues, and prvalues?

Quick A: Categories of values that determine what can be done with that value.

Some time ago on SO:

What are rvalues, lvalues, xvalues, glvalues, and prvalues?

What are these new categories of expressions?
The FCD (n3092) has an excellent description:

— An lvalue (so called, historically, because lvalues could appear on the left-hand side of an assignment expression) designates a function or an object. [ Example: If E is an expression of pointer type, then *E is an lvalue expression referring to the object or function to which E points. As another example, the result of calling a function whose return type is an lvalue reference is an lvalue. —end example ]

— An xvalue (an “eXpiring” value) also refers to an object, usually near the end of its lifetime (so that its resources may be moved, for example). An xvalue is the result of certain kinds of expressions involving rvalue references (8.3.2). [ Example: The result of calling a function whose return type is an rvalue reference is an xvalue. —end example ]

— A glvalue (“generalized” lvalue) is an lvalue or an xvalue.

— An rvalue (so called, historically, because rvalues could appear on the right-hand side of an assignment expressions) is an xvalue, a temporary object (12.2) or subobject thereof, or a value that is not associated with an object.

— A prvalue (“pure” rvalue) is an rvalue that is not an xvalue. [ Example: The result of calling a function whose return type is not a reference is a prvalue. The value of a literal such as 12, 7.3e5, or true is also a prvalue. —end example ]

Every expression belongs to exactly one of the fundamental classifications in this taxonomy: lvalue, xvalue, or prvalue. This property of an expression is called its value category. [ Note: The discussion of each built-in operator in Clause 5 indicates the category of the value it yields and the value categories of the operands it expects. For example, the built-in assignment operators expect that the left operand is an lvalue and that the right operand is a prvalue and yield an lvalue as the result. User-defined operators are functions, and the categories of values they expect and yield are determined by their parameter and return types. —end note

I suggest you read the entire section 3.10 Lvalues and rvalues though.
How do these new categories relate to the existing rvalue and lvalue categories?
Again:

Are the rvalue and lvalue categories in C++0x the same as they are in C++03?
The semantics of rvalues has evolved particularly with the introduction of move semantics.
Why are these new categories needed?
So that move construction/assignment could be defined and supported.

Quick Q: Does C++ final imply final in all aspects?

Quick A: Yes, a final class cannot have its methods overriden.

Recently on SO:

Does C++ final imply final in all aspects?

To quote the draft C++ standard from here [class.virtual/4]:

If a virtual function f in some class B is marked with the virt-specifier final and in a class D derived from B a function D::f overrides B::f, the program is ill-formed.
And here [class/3]:
If a class is marked with the class-virt-specifier final and it appears as a base-type-specifier in a base-clause (Clause [class.derived]), the program is ill-formed.
So, in answer to the question;

 

Does a final class implicitly imply its virtual functions to be final as well? Should it? Please clarify.

So, at least not formally. But attempts to violate either rule will be the same result in both cases; the program is ill-formed and so won't compile. A final class means the class cannot be derived from, so as a consequence of this, its virtual methods cannot be overridden.

 

Should it? Probably not, they are related but they not the same thing. There is also no need formally require the one to imply the other, the effect follows naturally. Any violations have the same result, a failed compile (hopefully with appropriate error messages to distinguish the two).

The Ultimate Question of Programming, Refactoring, and Everything

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort.

The Ultimate Question of Programming, Refactoring, and Everything

by Andrey Karpov

From the article:

The scope of my interests − the C/C++ language and the promotion of code analysis methodology. I have been Microsoft MVP in Visual C++ for 5 years. The main aim of my articles and work in general - is to make the code of programs safer and more secure. I'll be really glad if these recommendations help you write better code, and avoid typical errors. Those who write code standards for companies may also find some helpful information here.

Overload 132 is now available

ACCU’s Overload journal of April 2016 is out. It contains the following C++ related articles.

Overload 132

From the journal:

The Tao of Scratch
Scratch is an environment designed to help young people learn to code. Patrick Martin walks us through it. by Patrick Martin

Knowledge-Sharing Architects As An Alternative to Coding Architects
Should architects write code? Sergy Ignatchenko explores this controversial subject. by Sergey Ignatchenko

QM Bites: Understand Windows OS Identification Preprocessor Macros
There’s confusion between user-defined and predefined Windows 32/64-bit operating-system identification macros. Matthew Wilson shines light on the issue. by Matthew Wilson

Why Collaboration is Key for QA Teams in an Agile World
Agile processes can have an impact on QA departments. Greg Law considers how they can adapt to survive and even thrive. by Greg Law

How to Diffuse Your Way Out of a Paper Bag
Diffusion models can be used in many areas. Frances Buontempo applies them to paper bag escapology. by Frances Buontempo

Stufftar
How do you quickly transfer data from one machine to another? Ian Bruntlett shows us the bash script he uses. by Ian Bruntlett

QM Bites: looping for-ever
Never-ending loop constructs can confound user and compiler in subtle ways. Matthew Wilson offers advice to maximise portability and transparency.

Using Enum Classes as Bitfields
Scope enums have many advantages over standard enums. Anthony Williams shows how to use them as bitmasks. by Anthony Williams

9.7 Things Every Programmer Really, Really Should Know
Most of us have heard of the twelve step program. Teedy Deigh introduces a 9.7 step plan for programmers.