Quick Q: Confused about vectors

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.

CppCast Episode 132: Boost Application Development with Antony Polukhin

Episode 132 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Antony Palukhin to talk about some of the Boost libraries he's contributed to including Any, Conversion, DLL, LexicalCast, Stacktrace, TypeTraits and Variant; as well as his Boost Application Development book.

CppCast Episode 132: Boost Application Development with Antony Polukhin

by Rob Irving and Jason Turner

About the interviewee:

Antony Polukhin was born in Russia. Since university days he started contributing to Boost and became a maintainer of the Boost.LexicalCast library. Today, he works for Yandex, helps Russian speaking people with C++ standardization proposals, consults Russian companies in C++, continues to contribute to the open source and to the C++ language in general. You may find his code in Boost libraries such as Any, Conversion, DLL, LexicalCast, Stacktrace, TypeTraits, Variant, and others.

C++ Tips of the Week

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.

C++ Weekly Episode 96: Transparent Lambda Comparators—Jason Turner

Episode 96 of C++ Weekly.

Transparent Lambda Comparators

by Jason Turner

About the show:

In this episode Jason explores the use of lambdas as comparators for the associative containers. Just how far can we take the use of lambdas? Variadic templates, forwarding references, multiple inheritance, variadic "using" declarations, local classes, transparent comparators and direct base class initialization are all utilized in this video.

A friendly type predicate—Andrzej KrzemieĹ„ski

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