Home » Blog » Tags » intermediate

intermediate

cppformat 3.0.0 and becomes fmt--Victor Zverovich

By Adrien Hamelin | May 9, 2016 01:15 PM | Tags: intermediate c++14

A new versionb of fmt is out:

cppformat 3.0.0 and becomes fmt

by Victor Zverovich

From the release:

The project has been renamed from C++ Format (cppformat) to fmt for consistency with the used namespace and macro prefix (#307). Library headers are now located in the fmt directory:

#include "fmt/format.h"

Including format.h from the cppformat directory is deprecated but works via a proxy header which will be removed in the next major version. The documentation is now available at http://fmtlib.net...

CppCon 2015 Better Code: Data Structures--Sean Parent

By Adrien Hamelin | May 5, 2016 11:22 PM | Tags: intermediate efficiency

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:

Better Code: Data Structures

by Sean Parent

(watch on YouTube) (watch on Channel 9)

Summary of the talk:

The standard library containers are often both misused and underused. Instead of creating new containers, applications are often structured with incidental data structures composed of objects referencing other object. This talk looks at some of the ways the standard containers can be better utilized and how creating (or using non-standard library) containers can greatly simplify code. The goal is no incidental data structures.

CppCon 2015 Writing Good C++14... By Default--Herb Sutter

By Adrien Hamelin | May 2, 2016 10:59 AM | Tags: intermediate c++14

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

By Adrien Hamelin | Apr 29, 2016 01:42 PM | Tags: intermediate c++14

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?

By Adrien Hamelin | Apr 28, 2016 12:57 PM | Tags: intermediate c++11

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?

By Adrien Hamelin | Apr 28, 2016 12:47 PM | Tags: intermediate c++11

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