How To Address 7 Major C++ Pain Points with CLion

By Anastasia Kazakiova

As we’ll discuss in this article, CLion can help C++ developers with most of these in various ways:

• Managing third-party libraries
• Improving build times
• Setting up a CI-pipeline
• Managing a CMake project
• Checking code for thread, memory and type safety issues on-the-fly
• Setting up a development environment from scratch
• Modernize your code

RFC - fat pointer class, evolution of YOMM2

I am preparing to release a new feature, a fat pointer class (virtual_ptr), that makes method dispatch even more efficient. Dispatching a method with one virtual argument via a virtual_ptr takes only three instructions and two independent memory reads. As an interesting side-effect, it is now possible to use YOMM2 with non polymorphic classes hierarchies.

Once I increase the semantic minor version number, I will mostly be stuck with the API. So, if you are interested and in the mood, please review the documentation.

Beyond this, I have been mulling a major version bump. There are a few stuff that are deprecated, and I would like to get rid of them.

Also, I wonder if it would be a good time to switch to C++20. The internals would be a lot simpler and cleaner if I could use concepts.

I have a few major developments on the radar:I have a few major developments on the radar:

• dispatch on std::any and std::variant
• "fat" versions of std::any and std::variant (in the manner of virtual_ptr)
• going headers only
• related to the former: tunable runtime
• quasi static initialization of method tables

I wonder if it would be better to wait until these items are completed before switching to C++20 and putting the C++17 code in bugfix only mode.

Finite State Machine with std::variant - Vending Machine

By Bartlomiej Filipek

Here’s a basic diagram that illustrates how the machine is going to work:

Following the model from the last article, each state and the event will be a separate small structure. Later we can “pack” them into std::variant.

C++23: The Next C++ Standard

By Rainer Grimm

The C++ Standards

C++ is more than 40 years old. What happened in the last years? Here is a simplified answer ending in C++23.

C++98

At the end of the 80ths, Bjarne Stroustrup and Margaret A. Ellis wrote their famous book Annotated C++ Reference Manual (ARM). These books served two purposes. First, there were many independent C++ implementations. ARM defined, therefore, the functionality of C++. Second, ARM was the base for the first C++ standard: C++98 (ISO/IEC 14882). C++98 had a few essential features: templates, the standard template library (STL) with its containers and algorithms, strings, and IO streams.

C++03

With C++03 (14882:2003), C++98 got a technical correction that is so small that there is no place on my timeline. In the community, C++03, which includes C++98, is called legacy C++.

Back to Basics: Debugging in C++

by Mike Shah

Constrain Your User-Defined Conversions

By Jonathan Mueller

Sometimes you want to add an implicit conversion to a type. This can be done by adding an implicit conversion operator. For example, std::string is implicitly convertible to std::string_view:

	class string { // template omitted for simplicity
	public:
	    operator std::string_view() const noexcept
	    {
	       return std::string_view(c_str(), size());
	    }
	}; 

The conversion is safe, cheap, and std::string and std::string_view represent the same platonic value — we match Tony van Eerd’s criteria for implicit conversions and using implicit conversions is justified.

However, even when all criteria are fulfilled, the conversion can still be dangerous.

Thread-Safe Queue - Two Serious Errors

by Rainer Grimm

First, I want to show you again the erroneous implementation from my last post to understand the context.

// monitorObject.cpp

#include <condition_variable>
#include <functional>
#include <queue>
#include <iostream>
#include <mutex>
#include <random>
#include <thread>

class Monitor {
public:
    void lock() const {
        monitMutex.lock();
    }

    void unlock() const {
        monitMutex.unlock();
    }

    void notify_one() const noexcept {
        monitCond.notify_one();
    }

    template <typename Predicate>
    void wait(Predicate pred) const {                 // (10)
        std::unique_lock<std::mutex> monitLock(monitMutex);
        monitCond.wait(monitLock, pred);
    }
  
private:
    mutable std::mutex monitMutex;
    mutable std::condition_variable monitCond;
};

template <typename T>                                  // (1)
class ThreadSafeQueue: public Monitor {
public:
    void add(T val){
        lock();
        myQueue.push(val);                             // (6)
        unlock();
        notify_one();
    }
  
    T get(){
        wait( [this] { return ! myQueue.empty(); } );  // (2)
        lock();
        auto val = myQueue.front();                    // (4)
        myQueue.pop();                                 // (5)
        unlock();
        return val;
    }

private:
    std::queue<T> myQueue;                            // (3)
};


class Dice {
public:
    int operator()(){ return rand(); }
private:
    std::function<int()> rand = std::bind(std::uniform_int_distribution<>(1, 6),
                                          std::default_random_engine());
};


int main(){
  
    std::cout << '\n';
  
    constexpr auto NumberThreads = 100;
  
    ThreadSafeQueue<int> safeQueue;                      // (7)

    auto addLambda = [&safeQueue](int val){ safeQueue.add(val);          // (8)
                                            std::cout << val << " "
                                            << std::this_thread::get_id() << "; ";
                                          };
    auto getLambda = [&safeQueue]{ safeQueue.get(); };  // (9)

    std::vector<std::thread> addThreads(NumberThreads);
    Dice dice;
    for (auto& thr: addThreads) thr = std::thread(addLambda, dice());

    std::vector<std::thread> getThreads(NumberThreads);
    for (auto& thr: getThreads) thr = std::thread(getLambda);

    for (auto& thr: addThreads) thr.join();
    for (auto& thr: getThreads) thr.join();
  
    std::cout << "\n\n";
   
}

C++ Lambda Idioms

by Timur Doumler

Ever since they were introduced in C++11, lambdas have been an essential language feature. Each subsequent standard added more functionality: we got generic lambdas and init captures in C++14, constexpr lambdas in C++17, default-construction and assignment, explicit template arguments and more in C++20, and even more possibilities are coming in the upcoming C++23 standard.

In this talk, we are looking at various interesting things you can do with lambdas. Some of these are well-established, useful idioms; others are lesser known, surprising tricks. Have you ever inherited from a lambda? Can you think of three different ways to call a lambda recursively? Do you know what happens if we assign an immediately-invoked lambda expression to a static variable? If not, then this talk is for you.

Object Ownership

By Ilya Doroshenko

Since we know the rules of new and delete, namely new allocates and delete destroys, we never really cared about who is responsible for the object. This caused a lot of confusion in the past. For instance, some API codes from Win32 return strings that should be LocalFree()d, like FormatMessage or GetEnvironmentStrings. POSIX, on the other hand, has strdup as a common example of you should free it yourself. This model is confusing because you may have a lot of return statements, before which you should always call free or delete, depending on the operation. However, we have RAII since the very beginning of C++, which adds constructors and destructors. So, in 1998 resourceful people decided to add auto_ptr to the standard.

The premise was simple:

• a simple explicit constructor, that took raw pointer from new
• destroyed by either an explicit release/reset or a destructor on the end of the block

This was the first attempt at a structured cleanup. As time passed, the initial point began to crumble. More issues arose and the question came up: Who owns the data?

C++ Coding with Neovim

by Prateek Raman

If the command line has ever piqued your interest, specially using Vim/Neovim for C++ coding, but you have some reservations about losing access to IDE like features, wonder no more. This talk will present a productive C++ development environment on the Command Line using Neovim and LSP. LSP (Language Server Protocol) is the protocol which powers semantic auto-completion and intellisense in modern IDEs and we'll learn how Neovim's built-in LSP client integrates seamlessly with language servers to provide a rich editing experience.

Neovim is a modern editor built on top off the giant shoulders of Vim, and lets us have all the speed and efficiency of Vim as we edit code, while also providing rich support for C++ coding with intellisense and auto-completion via LSP. Along the way we'll also demonstrate Neovim's rich LSP aware plugin ecosystem for project navigation and IDE like workflows, all on the command line.

Even if you're comfortable with Vim/Neovim, but would like to learn how to level up the experience with modern IDE features, you will find this talk interesting.