Articles & Books

Factory With Self-Registering Types—Bartlomiej Filipek

Let’s see how classes can register themselves in a factory and what are the examples where it’s used.

Factory With Self-Registering Types

by Bartlomiej Filipek

From the article:

In this post, I’ve covered a type of factory where types register themselves. It’s an opposite way of simple factories where all the types are declared upfront. Such approach gives more flexibility and removes dependency on the exact list of supported classes from the factory.

Read-Compile-Run-Loop - a tiny embeddable REPL analog for C++—Viktor Kirilov

Most scripting languages have REPLs (read-eval-print-loop) - an interactive console.

Read-Compile-Run-Loop - a tiny embeddable REPL analog for C++

by Viktor Kirilov

From the article:

Ever wanted to modify some value or execute some (complex) statement while your C++ program is running just to test something out? Something that cannot be done through the debugger or wouldn’t be trivial? Scripting languages have REPLs and it's time for C++ to get one too.

To RAII or Not to RAII?—Jonathan Boccara

Good question.

To RAII or Not to RAII?

by Jonathan Boccara

From the article:

RAII is a central concept in C++, that consists in relying on the compiler to call destructors automatically in certain cases. Putting appropriate code in such destructors then relieves us from calling that code – the compiler does it for us.

RAII is an idiomatic technique of C++, but can we use RAII for everything? Is it a good idea to shift every possible piece of code to the destructor of some class, to leave the work to the compiler and make calling code as light as can be?

Since this question comes down to asking if the proverbial hammer is a tool fit for every single task, the answer to that question is probably the proverbial No.

But then, in which cases would RAII improve the design of a piece of code?

In this article we’ll see a case where RAII is adapted, then a case where RAII is NOT adapted. And after that we’ll see a case open to discussion. We’ll then conclude with how to use levels of abstractions to make the decision to RAII or not to RAII...

Overload 143 is now available

ACCU’s Overload journal of February 2018 is out. It contains the following C++ related articles.

Overload 143 is now available

From the journal:

Hapaxes, Singletons and Anomalies
Programmers can be odd. Frances Buontempo celebrates many manifold peculiarities. by Frances Buontempo

A Wider Vision of Software Development
Is code a hopeful arrangement of bytes? Charles Tolman brings his Organising Principles series to a close. by Charles Tolman

An MWSR Queue with Minimalist Locking
Multithreaded queues come in many flavours. Sergey Ignatchenko describes his implementation of a multiple writer single reader queue. by Sergey Ignatchenko

Testing: Choose the Right Level
Testing can be easy. Andy Balaam considers levels to keep your focus just right. by Andy Balaam

CTAD – What Is This New Acronym All About?
What is class template argument deduction? Roger Orr elucidates this new C++17 feature. by Roger Orr

C++ with Meta-classes?
Meta-classes will allow us to detail class requirements. Francis Glassborow compares them to developments of C++ in the 1990s. by Francis Glassborow

Practical Scale Testing
Everyone wants scalable systems. Arun Saha explores methods for testing scalability. by Arun Saha

Functional Error-Handling with Optional and Expected
Exceptions should be exceptional. Simon Brand shows modern alternatives from the standard library and ways to improve them. by Simon Brand

Introduction to the C++ Ranges Library—Jonathan Boccara

You can read it or watch it.

Introduction to the C++ Ranges Library

by Jonathan Boccara

From the article:

Do you know the ranges library in C++?

This video will show what limitations of the STL it solves, and how it can make C++ code more expressive.

Since some of you expressed that they liked text more than videos, I’ve included a transcript of the video. I’d be glad to know if you find this useful, and if you’d like to have a transcript for other videos...

CopperSpice: Threads and Containers

New videos on the CopperSpice YouTube Channel:

Modern C++ Threads

by Barbara Geller and Ansel Sermersheim

About the video:

An overview of the C++11 threading library, including a discussion of why the C++11 memory model is so important. We also present information about atomics and the abstraction of multithreaded design.

What's in a container?

by Barbara Geller and Ansel Sermersheim

About the video:

A practical look at how containers are implemented in C++, including a discussion of when you should implement your own container, the potential pitfalls of hand-rolled containers, why Copy-On-Write is a bad idea and disallowed for containers in the standard library, and how to implement your own container adapters.

Please take a look and remember to subscribe!

Quick Q: Direct initialization with empty initializer list

Quick A: If there is an initializer list contructor, it will choose it.

Recently on SO:

Direct initialization with empty initializer list

When an argument is an initializer list ([dcl.init.list]), it is not an expression and special rules apply for converting it to a parameter type.

If the parameter type is std::initializer_list or “array of X” and all the elements of the initializer list can be implicitly converted to X, the implicit conversion sequence is the worst conversion necessary to convert an element of the list to X. This conversion can be a user-defined conversion even in the context of a call to an initializer-list constructor.

Otherwise, if the parameter is a non-aggregate class X and overload resolution per [over.match.list] chooses a single best constructor of X to perform the initialization of an object of type X from the argument initializer list, the implicit conversion sequence is a user-defined conversion sequence. If multiple constructors are viable but none is better than the others, the implicit conversion sequence is the ambiguous conversion sequence. User-defined conversions are allowed for conversion of the initializer list elements to the constructor parameter types except as noted in [over.best.ics].

Quick Q: Uses of destructor = delete;

Quick A: If you have an object which should never, ever be deleted or stored on the stack (automatic storage), or stored as part of another object, =delete will prevent all of these.

Recently on SO:

Uses of destructor = delete;

struct Handle {
  ~Handle()=delete;
};

struct Data {
  std::array<char,1024> buffer;
};

struct Bundle: Handle {
  Data data;
};

using bundle_storage = std::aligned_storage_t<sizeof(Bundle), alignof(Bundle)>;

std::size_t bundle_count = 0;
std::array< bundle_storage, 1000 > global_bundles;

Handle* get_bundle() {
  return new ((void*)global_bundles[bundle_count++]) Bundle();
}
void return_bundle( Handle* h ) {
  Assert( h == (void*)global_bundles[bundle_count-1] );
  --bundle_count;
}
char get_char( Handle const* h, std::size_t i ) {
  return static_cast<Bundle*>(h).data[i];
}
void set_char( Handle const* h, std::size_t i, char c ) {
  static_cast<Bundle*>(h).data[i] = c;
}

Here we have opaque Handles which may not be declared on the stack nor dynamically allocated. We have a system to get them from a known array.

I believe nothing above is undefined behavior; failing to destroy a Bundle is acceptable, as is creating a new one in its place.

And the interface doesn't have to expose how Bundle works. Just an opaque Handle.

Now this technique can be useful if other parts of the code need to know that all Handles are in that specific buffer, or their lifetime is tracked in specific ways. Possibly this could also be handled with private constructors and friend factory functions.

Why it is important to check what the malloc function returned

Unfortunately, many programmers are careless about checking of pointers, and sometimes they deliberately do not check whether to memory was allocated or not.

Why it is important to check what the malloc function returned

by Andrey Karpov

From the article:

There are 4 reasons at once, each of them is enough to prove that it is so necessary to write a check after you call the malloc function. If someone from your team doesn't write the checks, make him read this article.

  1. Null pointer dereference is undefined behavior
  2. Null pointer dereference is a vulnerability
  3. Where are guarantees that dereferencing of exactly a null pointer will occur?
  4. Where are the guarantees that memset fills the memory in a direct order?