intermediate

Refactoring with C++17 std::optional—Bartlomiej Filipek

Isn't it better?

Refactoring with C++17 std::optional

by Bartlomiej Filipek

From the article:

There are many situations where you need to express that something is “optional” - an object that might contain a value or not. You have several options to implement such case, but with C++17 there’s probably the most helpful way: std::optional.

For today I’ve prepared one refactoring case where you can learn how to apply this new C++17 feature...

How to Reorder A Collection With the STL—Jonathan Boccara

Did you know?

How to Reorder A Collection With the STL

by Jonathan Boccara

From the article:

The STL lets you do plenty of things on collections, and one of them is to reorder the elements inside of the collection. Or, said another way, to perform a permutation on the collection.

Inded, moving elements around a collection typically takes a fair amount of complex code to write, involving for loops and iterators. And it is perhaps the area where the STL generates the most spectacular improvements, by encapsulating those complex operations behing meaningful interfaces.

Let’s see what sorts of permutations the STL offers:

  • Lexicographical permutations
  • Cyclic permutations
  • Random permutation
  • Reverse
  • Checking for permutations
  • Other permutations

optional in Containers Ⅱ — Not All std::vector Usages Are The Same—Jonathan Müller

What do you think?

optional<T> in Containers Ⅱ — Not All std::vector Usages Are The Same

by Jonathan Müller

From the article:

Okay, so in the previous post I talked about putting optional<T> in container. I came to conclusions which I though were reasonable at the time, however, people — rightfully — pointed out some flaws in my argumentation...

How to Pass a Polymorphic Object to an STL Algorithm—Jonathan Boccara

Did you ever try?

How to Pass a Polymorphic Object to an STL Algorithm

by Jonathan Boccara

From the article:

As we can read in the opening chapter of Effective C++, C++ is a federation of 4 languages:

  • the procedural part coming from C,
  • the object-oriented part,
  • the STL part (following a functional programming paradigm),
  • the generic part with templates.

And what’s more, all of those 4 sub-languages are part of one whole: the C++ language. Those 4 paradigms begin united in one language gives opportunities for them to interact – and often, those interactions create interesting situations.

Today we’re focusing on one particular interaction, between the object-oriented model and the STL. There could be multiple forms for this interaction, and the case we will look at is how to pass a polymorphic (that is, having virtual methods) function object to an STL algorithm.

Which One Is Better: Map of Vectors, or Multimap?—Jonathan Boccara

Depends!

Which One Is Better: Map of Vectors, or Multimap?

by Jonathan Boccara

From the article:

While advising on how to make code more expressive on the SFME project, I came across an interesting case of choosing the right data structure, which I’ll share with you with the permission of the authors of the projects.

We had to associate a key with several values, and perform various operations. Should we use a map of vectors, or is a multimap more appropriate? Let’s see the case in more details, and compare the two solutions...

Getting the Benefits of Strong Typing in C++ at a Fraction of the Cost—Vincent Zalzal

Very interesting!

Getting the Benefits of Strong Typing in C++ at a Fraction of the Cost

by Vincent Zalzal

From the article:

Strong types promote safer and more expressive code. I won’t repeat what Jonathan has presented already in his series on strong types.

I suspect some people may find that the NamedType class template has a nice interface but is using a somewhat heavy machinery to achieve the modest goal of strong typing. For those people, I have good news: you can achieve many of the functionalities of NamedType, with a very simple tool. That tool is the humble struct...

Quick Q: Why does unary operator & not require a complete type?

Quick A: It only need to take the address.

Recently on SO:

Why does unary operator & not require a complete type?

What if stru has overloaded operator&()?

Then it is unspecified whether the overload will be called (See Oliv's comment for standard quote).

How could unary operator & does not require a complete type?

That's how the standard has defined the language. The built-in address-of operator doesn't need to know the definition of the type, since that has no effect on where to get the address of the object.

One consideration for why it is a good thing: Compatibility with C.