Articles & Books

Quick Q: What is a non-trivial constructor in C++?

Quick A: All constructors that you define are not trivial.

Recently on SO:

What is a non-trivial constructor in C++?

In simple words a "trivial" special member function literally means a member function that does its job in a very straightforward manner. The "straightforward manner" means different thing for different kinds of special member functions.

For a default constructor and destructor being "trivial" means literally "do nothing at all". For copy-constructor and copy-assignment operator, being "trivial" means literally "be equivalent to simple raw memory copying" (like copy with memcpy).

If you define a constructor yourself, it is considered non-trivial, even if it doesn't do anything, so a trivial constructor must be implicitly defined by the compiler.

In order for a special member function to satisfy the above requirements, the class must have a very simplistic structure, it must not require any hidden initializations when an object is being created or destroyed, or any hidden additional internal manipulations when it is being copied.

For example, if class has virtual functions, it will require some extra hidden initializations when objects of this class are being created (initialize virtual method table and such), so the constructor for this class will not qualify as trivial.

For another example, if a class has virtual base classes, then each object of this class might contain hidden pointers that point to other parts of the very same object. Such a self-referential object cannot be copied by a simple raw memory copy routine (like memcpy). Extra manipulations will be necessary to properly re-initialize the hidden pointers in the copy. For this reason the copy constructor and copy-assignment operator for this class will not qualify as trivial.

For obvious reasons, this requirement is recursive: all subobjects of the class (bases and non-static members) must also have trivial constructors.

A Foolish Consistency--Jon Kalb

A very interesting article that we should all read.

A Foolish Consistency

by Jon Kalb

From the article:

Ralph Waldo Emerson famously said, “A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.” I don’t think he was talking about code, but that statement couldn’t be more relevant to software engineers.

I’ve experienced a scenario like this a number of time in my career:

I’m sharing a new approach to writing code that offers some clear improvements to what we’ve been doing. Perhaps it is more readable, more efficient, or safer. But the response that I hear from colleagues is, “But we can’t do that here. We have <some large number> lines of code where we didn’t do it that way, so it wouldn’t be consistent.”

C++17 Features, in easy to understand before/after tables -- Tony Van Eerd

Results of a recent survey suggest that many devs have a hard time keeping up with changes between each rev of C++.

C++17 before and after table

by Tony Van Eerd

About the article:

Here's a collection of the major changes between C++14 and C++17, with example code for each - typically showing how it may have been written before C++17, and how it can now be written with the new C++17 feature(s).

 

 

C++ Rename Shootout: Visual Studio 2017 vs. ReSharper for C++ -- Richard Thomson

A comparison of two automatic rename tools for C++ in Visual Studio.

C++ Rename Shootout: Visual Studio 2017 vs. ReSharper for C++

by Richard Thomson

About the post:

Getting help from your development environment for renaming identifiers can be a huge productivity boost. It lets you quickly and easily improve the names of things in your code. In this post, I’ll review two automatic renaming tools for C++ in Visual Studio: Visual Studio 2017 Community Edition 15.5.7 and ReSharper for C++ 2017.3.2.

Selective argument application -- Krzysztof Ostrowski

Presentation of a technique that enables transparent interception of the selected arguments passed to any function by means of a user-provided predicate metafunction.

Selective argument application

by Krzysztof Ostrowski

From the article:

Presentation of a design of an interceptor abstraction built over C++17 utilities that records values of the selected arguments passed to any action transparently, then applies that action to the captured arguments, and eventually passes the result value to the next action.

RIP index_sequence, 2014–2017 -- Matt Aubury

Matt Aubury philosophizes about digging a grave for certain std::index_sequence idioms. 

RIP index_sequence, 2014–2017

by Matt Aubury

From the article:

std::tuple was one of the great additions to C++11. Whilst sometimes abused by lazy programmers (who should really be using a struct or class), it’s true value is as a container of arbitrary values in variadic templates.

Sadly, static typing makes working with tuples much harder in C++ than in most languages [...]

What are the C and C++ Standard Libraries?

A brief tour into the realm of writing C and C++ applications, the role of the Standard Library and how it is implemented in various operating systems.

What are the C and C++ Standard Libraries?

By Triangles @ Internal Pointers

From the article:

I have been playing around with C++ for a while and one thing that always got me confused in the beginning was its anatomy: where do the core functions and classes I'm using come from? Who invented them? Are they packaged somewhere in my system? Is there a kind of official C++ manual around?

What Should Go Into the Standard Library -- Titus Winters

Titus responds to Guy Davidson's article, what should go into the STL.

What Should Go Into the C++ Standard Library

By Titus Winters

From the article:

So, what should go in the standard library? Fundamentals. Things that can only be done with compiler support, or compile-time things that are so subtle that only the standard should be trusted to get it right. Vocabulary. Time, vector, string. Concurrency. Mutex, future, executors. The wide array of “sometimes useful data structure” and “random metaprogramming” could and should be shuffled off into a semi-standard repository of available but distinct utility libraries. Those may themselves have different design and stability philosophies, like Boost or Abseil - the principles that make the standard what it is are not necessarily universal even if they are good for the standard. Graphics is too much - many won’t want it, and those that think they do may not understand what they are asking for.

optional in a possible C++20 future--Barry Revzin

Lots of proposals:

optional<T> in a possible C++20 future

by Barry Revzin

From the article:

C++17 gave us std::optional which is, in the words of a friend of mine, one of those really simple, ultra complex types — in the sense that it’s very easy to understand and use properly, even for relatively inexperienced programmers… but extremely difficult to implement correctly, even for experts (another such is std::pair). Today, it’s well over a thousand lines of code, most of which is critical to support even its most basic functionality. optional<T> is the simplest sum type, and it appears in lots of different languages (and even has special syntax in Swift) under various related names — Maybe, Option, etc. — but in the languages I’m even nominally familiar with, it’s about as simple to implement as it is to use.

But that’s the state of affairs today. What does tomorrow bring?