Home » Blog » Categories » Articles & Books

Articles & Books

Introduction to std::chrono--Rachel Crawford

By Adrien Hamelin | Jan 10, 2018 02:35 PM | Tags: intermediate c++11

How to measure time in C++?

Introduction to std::chrono

by Rachel Crawford

From the article:

How many times have you tried to call a function that alleges to return a time value only to realise you don’t know what units the value is in? Or that takes a time value as a parameter, but doesn’t specify whether the value is expected to be in milliseconds, seconds, or hours?

Chaining Comparisons: Seeking Information from the Audience--Barry Revzin

By Adrien Hamelin | Jan 10, 2018 02:26 PM | Tags: experimental community

A nice example of committee members reaching out to the community for data/input on proposed changes that could have a breaking impact.

Chaining Comparisons: Seeking Information from the Audience

by Barry Revzin

From the article:

At the last standards committee meeting in Albuquerque, the spaceship operator was adopted into the working draft for what will eventually be C++20. I’m already pretty excited about that. But one of the initial “optional” parts of Herb Sutter’s original spaceship proposal (which was dropped early) was to support chaining comparisons...

Quick Q: Function not called in code gets called at runtime

By Adrien Hamelin | Jan 8, 2018 12:26 PM | Tags: intermediate

Quick A: undefined behaviour can result in anything.

Recently on SO:

Function not called in code gets called at runtime

The program contains undefined behavior, as dereferencing a null pointer (i.e. calling foo() in main without assigning a valid address to it beforehand) is UB, therefore no requirements are imposed by the standard.

Executing never_called at runtime is a perfect valid situation when undefined behavior has been hit, it's as valid as just crashing (like when compiled with GCC). Okay, but why is Clang doing that? If you compile it with optimizations off, the program will no longer output "formatting hard disk drive", and will just crash...

Quick Q: Confused about vectors

By Adrien Hamelin | Jan 8, 2018 11:32 AM | Tags: basics

Quick A: Do not confuse mathematical concepts with C++ terminology.

Recently on SO:

Confused about vectors

You are getting confused because the mathematical concept of a vector can mean a "collection of data" and that is what you were taught int v[10] was. The actual name for that in C++ (and most other languages) is an "array" not a vector.

The libraries referred to in C++ Primer have a class called "vector" which is an implementation of an array. They are similar, but not the same.

I hope that clears that up a bit. You are probably confused because you were taught that int v[10] is a vector, but it is "not really" in C++. It's an array. Use that term to refer to it. If you ever refer to it as a vector, you will confuse others and yourself.

C++ Tips of the Week

By shreck | Jan 2, 2018 11:52 AM | Tags: None

Google's internal C++ tips are going public:

Abseil Publishing Google's C++ "Tips of the Week"

By Tom Manshreck, Abseil and C++ Tech Writer

From the article:


Background: About five years ago, within Google we started publishing a series of C++ tips, about once a week, that became known as the “C++ Tips of the Week” (TotW). They became wildly successful, and we are still publishing them to this day (indicating that a language as rich as C++ will not deplete us of topics anytime soon).

Not only do we discuss the finer points of the language, but in true “tip” fashion, offer our advice or design preferences. The collective set of C++ TotW has become a canon within Google itself, cited thousands of times per week in code reviews and internal mailing list discussions. Often they are cited by number, and some have become known simply as “totw/110” or “totw/77”.

We’ve decided to expose most of these tips to the Abseil development community, and the C++ community at large.

A friendly type predicate--Andrzej KrzemieĊ„ski

By Adrien Hamelin | Dec 27, 2017 10:38 AM | Tags: intermediate c++11

To improve the error messages.

A friendly type predicate

by Andrzej Krzemieński

From the article:

This is a sequel to the previous post on writing a custom type predicate. One of the readers on Reddit made a very insightful observation. The user has implemented a type that she intends to use with our library, call it Calc. She passes it to the library function, and she gets the compiler error:

static assertion failed: X does not have a desired interface

But what is our type missing? In the previous post we were describing 3 constraints. A concept could have far more of them. The user has already made an effort to have Calc comply with the constraints, so there must be something tiny missing. Maybe there is a bug in the implementation of the predicate? But it is difficult to track what it is that the predicate does not like about our type. We could use some more specific information...