February 2018

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.

ACCU 2018 Schedule has been published -- ACCU conference committee

The schedule for the upcoming ACCU 2018 conference in Bristol, UK from 2018-04-11 to 2018-04-14 has been published.

ACCU 2018 Schedule

by ACCU conference committee

About the conference:

Again we have three C++ tracks this year!

We will have keynotes by Gen Ashley, Hadi Hariri, Lisa Lippincott and Seb Rose.

Four full day tutorials take place the day before the conference, three with C++ content.

So don't forget to register.

CppCast Episode 136: foonathan/type_safe and more with Jonathan Müller

Episode 136 of CppCast the only podcast for C++ developers by C++ developers. In this episode Rob and Jason are joined by Jonathan Müller to talk about his experience at University and some of his recent projects.

CppCast Episode 136: foonathan/type_safe and more with Jonathan Müller

by Rob Irving and Jason Turner

About the interviewee:

Jonathan is a CS student passionate about C++. In his spare time he writes libraries like foonathan/memory which provides memory allocator implementations. He is also working on standardese which is a documentation generator specifically designed for C++. Jonathan tweets at @foonathan and blogs about various C++ and library development related topics at foonathan.net.

N4720: Working Draft, Extensions to C++ for Modules -- Gabriel Dos Reis

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4720

Date: 2018-01-29

Working Draft, Extensions to C++ for Modules

by Gabriel Dos Reis

Excerpt:

As approved between meetings as a current working draft base for further proposal discussion in Jacksonville.

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?

CppDepend v2018.1 Released - CERT/HICPP standard Checks, C++ Core guidelines support and much more.

We are happy to inform you that CppDepend v2018.1 has been released and is now available for download!

More Information about CppDepend v2018.1 new features!

by CoderGears

About the release:

CppDepend v2018.1 allows architects and developers to analyze C and C++ code base. Measure, query and visualize source code and avoid unexpected issues, technical debt and complexity.

Start your 1-month free trial!

About the release

With CppDepend v2018.1 Save time, reduce costs and deliver high-quality code with these important updates:

  • CERT (SEI CERT C++ Coding Standard ) standard checks
  • HICPP (High Integrity C++) standard checks
  • More rules to check your modern C++ codebase(C++11,C++14,C++17): More than 20 modernization detections
  • Clang-tidy tool embedded for more issues detection
  • Analysis of the CMake format specification: CppDepend analyzes now out of the box the CMake Compilation Database Format Specification.
  • C++ Core Guidelines support
  • New rules related to the performance and the readability issues

 

The Most Vexing Parse: How to Spot It and Fix It Quickly--Jonathan Boccara

Did you have that problem?

The Most Vexing Parse: How to Spot It and Fix It Quickly

by Jonathan Boccara

From the article:

Everyone has their little defaults. You know, that little something that they do from time to time and that gets on your nerves, even though they’re otherwise nice people?

For C++, one of these little annoyances is the most vexing parse, well, as its name suggests...