basics

Better C++ / Chicago July 12-14, 2017

Join us for a 3 day training event in Chicago, IL, USA July 12-14, 2017

Better C++ / Chicago

by Jason Turner

About the training:

Through this training you will gain a better understanding of how to write clean, maintainable, and well performing C++ code.

The topics covered apply to all types of C++ development: embedded, system or application development.

Jason's classes are highly interactive and have a limited class size to ensure that everyone has sufficient opportunity to participat

A la carte tickets are available for those wishing to attend only part of the training.

Wednesday: Demystifying C++11 and Beyond

C++11, 14, and 17 added many new features to C++ that have made many question the overhead of using these new features and the complexity they add to the language. We will make an in depth examination of these features to give you confidence in using and deploying modern C++ techniques in your organization.

Thursday: Understanding Object Lifetime in C++

C++ has what very few other languages have: a well defined object life cycle. Understanding this key aspect of the language is critical for writing high quality C++.
We will describe the lifecycle of an object in C++ and work through increasingly complex examples. There will be something for C++ developers of all skill levels to learn.

Friday: C++ Best Practices

On the final day of the course we will cover a series of tangible best practice rules for how to write C++ code that is maintainable and efficient by default.
We will wrap up with a discussion of how to use the tools available to maintain code quality.

Quick Q:Is there a way to mark a parent's virtual function final from a child class?

Quick A: No.

Recently on SO:

Is there a way to mark a parent's virtual function final from a child class without reimplementing it

No, you can't do it without reimplementing it. So just reimplement it:

struct Child : public Parent
{
    virtual void fn() override final { Parent::fn(); }
};

N.B. saying virtual ... override final is entirely redundant, final is an error on a non-virtual function, so you should just say:

    void fn() final { Parent::fn(); }

See http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override

Quick Q: shrink_to_fit() vs swap trick

Quick A: Are equivalent, but shrink_to_fit mark the intention.

Recently on SO:

shrink_to_fit() vs swap trick

The swap trick isn't actually constant-time. The cost of performing the actual swap is indeed O(1), but then there's the cost of the std::vector destructor firing and cleaning up all the allocated space. That can potentially have cost Ω(n) if the underlying objects have nontrivial destructors, since the std::vector needs to go and invoke those destructors. There's also the cost of invoking the copy constructors for all the elements stored in the initial vector, which is similarly Ω(n).

As a result, both approaches should have roughly the same complexity, except that shrink_to_fit more clearly telegraphs the intention and is probably more amenable to compiler optimizations.

Quick Q: Syntax of final, override, const with trailing return types

Quick A: The signature of the function is first.

Recently on SO:

Syntax of final, override, const with trailing return types

The correct syntax should be:

  • override and final should appear after the member function declaration, which including the trailing return type specification, i.e.
auto debug(ostream& os=cout) const ->ostream& override final;
  • override and final should not be used with the member function definition outside the class definition, so just remove them:
auto Derived::debug(ostream& os) const ->ostream&
{
  os << "dval: " << dval << endl;
  return os;
}

Quick Q: Are the experimental features of modern C++ reliable for long-term projects?

Quick A: No

Recently on SO:

Are the experimental features of modern C++ reliable for long-term projects?

Is it guaranteed that all compliant compilers have the same experimental features?
No, experimental features are optional.
Are experimental features prone to big changes that make them unreliable?
Yes, the C++ committee might even decide to abandon a feature or in the process of standardization a defect might come up that would force a feature to change.

Generally, it's not a good idea to depend on experimental features. Experimental features are exactly what the word says (i.e., to experiment with).

C++ Braced Initialization--Edouard of quasardb

Do you use it?

C++ Braced Initialization

by Edouard of quasardb

From the article:

Since C++ 11 it's possible to use braces for construction and initialization. Although this is something you could ignore for the code you write, it's obviously important to know for the code you may read.

If you have a couple of years of experience in C++, the temptation can be great to keep your old habits because "All these new features are useless! The language is bloated! Those people in the committee!".

Let's make sense out of the bloat...