SObjectizer Tales – 4. Handling commands--Marco Arena

By Marco Arena | Nov 2, 2023 01:29 AM | Tags: sobjectizer intermediate c++20

A new episode of the series about SObjectizer and message passing:

SObjectizer Tales – 4. Handling commands

by Marco Arena

From the article:

What if we could seamlessly command the device to start and stop its acquisition with the wave of our virtual wand?

On Writing Loops in PPL and Continuation-passing Style, Part 3 -- Raymond Chen

By Blog Staff | Oct 31, 2023 02:49 PM | Tags: None

In our previous discussion, we optimized a task-based while loop by eliminating nested shared pointers, instead requiring all the state to reside inside a caller-provided shared_ptr, making the callable stateless. This approach simplifies the code and reduces redundancy in managing state.

On Writing Loops in PPL and Continuation-passing Style, Part 3

By Raymond Chen

From the article:

Last time, we wrote a task-based while loop using recursion, using a shared_ptr to pass state, and we noted a redundancy in that we created a shared_ptr to a lambda that in turn held a shared_ptr.

We can eliminate the nested shared pointers by requiring that all the state live inside a caller-provided shared_ptr, levaing the callable stateless.

template<typename State>
task<void> do_while_task(
    std::shared_ptr<State> const& state,
    bool (*f)(std::shared_ptr<State> const&)
{
    return f(state).then([state, f](bool loop) {
        return loop ? do_while_task(state, f) :
                      task_from_result();
    });
}

struct lambda_state
{
    lambda_state(Widgets* w) : widgets(w) {}
    Widgets* widgets;
    int i = 0;
};

auto state = std::make_shared<lambda_state>(widgets);

do_while_task(state, [](auto&& state)
{
    if (state->i >= 3) return task_from_result(false);
    return create_widget().then([state](auto widget)
    {
        state->widgets[state->i] = widget;
        state->i++;
        return true;
    }
}).then([] {
    printf("Done!\n");
});

We can get rid of all the state-> prefixes by making the state be invocable.

Beautiful C++: 30 Core Guidelines... Book Review -- Bartlomiej Filipek

By Blog Staff | Oct 27, 2023 02:45 PM | Tags: None

This is a book review of “Beautiful C++,” written by two well-known C++ experts and educators: Kate Gregory and Guy Davidson. The book’s unique style gives us a valuable perspective on effective and safe C++ code.

Beautiful C++: 30 Core Guidelines... Book Review

By Bartlomiej Filipek

From the review:

The book is split into five parts, and each part has six guidelines to help us understand the material more easily.

• Part one: Bikeshedding is bad - how to reduce the number of lines of your code and simplify it. For example, by using use in-class member initializers or avoiding getters and setters.
• Part two: Don’t hurt yourself - how to avoid messy code and minimize complexity. For example, by limiting explicit sharing of variables, proper use of ABI and more.
• Part three: Stop using that - some important bugs and bad C++ code style: singletons, casting away const or unsafe managing the ownership of resources.
• Part four: Use this new thing properly - efficient use of modern C++ style: enum classes, constexpr, templates.
• Part five: Write code well by default - good patterns for your code: type safety, immutable data structures avoiding uninitialized variables, and RAII.

In total, it’s around 300 pages + afterword and index.

If we look at a corresponding guideline like I.3: Avoid singletons you’ll see a short paragraph of introduction, some small example and a short discussion to alternatives. On the other hand, in the book, this guideline consists of 9 pages with unique examples, backstories, alternatives and discussions. The section shows things like:

• Why global objects are bad
• Singleton Design pattern overview
• Static initialization order fiasco
• Hiding singletons and making a namespace rather than a class
• And even how to use constexpr in some cases (constexpr is also covered in other sections)

SObjectizer Tales – 3. Acquisition loop revisited--Marco Arena

By Marco Arena | Oct 26, 2023 01:53 AM | Tags: sobjectizer intermdiate c++20

A new episode of the series about SObjectizer and message passing:

SObjectizer Tales – 3. Acquisition loop revisited

by Marco Arena

From the article:

Maybe you have already realized what we are getting at. Conceptually, a loop is just a series of iterations...

On Writing Loops in PPL and Continuation-passing Style, Part 2 -- Raymond Chen

By Blog Staff | Oct 25, 2023 02:42 PM | Tags: None

In our previous discussion, we explored a task-based while loop employing custom callables that passed copies of themselves to the next iteration, which follows the continuation-passing style used in the Parallel Patterns Library (PPL). In this session, we will implement the same function using a more traditional recursive approach, aiming to simplify the sharing of state between lambda callables in PPL-style programming.

On Writing Loops in PPL and Continuation-passing Style, Part 2

By Raymond Chen

From the article:

Last time, we came up with task-based while loop that involved creating a custom callable that passed copies of itself to the next iteration.

This time, we’ll implement the function in terms of a more traditional recursion.

template<typename Callable>
task<void> do_while_task(
    std::shared_ptr<Callable> const& f)
{
    return (*f)().then([f](bool loop) {
        return loop ? do_while_task(f) :
                      task_from_result();
    });
}

template<typename Callable, typename =
    std::enable_if_t<std::is_invocable_v<Callable>>>
task<void> do_while_task(Callable&& callable)
{
    using Decayed = std::decay_t<Callable>;
    return do_while_task(
        std::make_shared<Decayed>(
            std::forward<Callable>(callable)));
}

The real work happens in the first overload, which takes a ready-made shared_ptr. The second overload is a convenience method that lets you pass a callable, and it will wrap it in a shared_ptr for you.

On Writing Loops in PPL and Continuation-passing Style, Part 1 -- Raymond Chen

By Blog Staff | Oct 23, 2023 02:35 PM | Tags: None

The Parallel Patterns Library (PPL) relies on a continuation-passing style for asynchronous programming, where tasks are invoked and then linked to callable objects that process their results. This approach was the primary method for handling asynchronous operations before the introduction of await and co_await keywords in C#, JavaScript, and C++, making it essential to understand for developers working with older code or scenarios that still employ this style.

On Writing Loops in PPL and Continuation-passing Style, Part 1

By Raymond Chen

From the article:

The Parallel Patterns Library (PPL) is based on a continuation-passing style, where you invoke a task, and then attach a callable object that will be given the result. Prior to the introduction of the await and co_await keywords to C#, JavaScript, and C++, this was your only real choice for asynchronous programming.

Sequential calculations are fairly straightforward in continuation-passing style because you just pass the next step as the continuation.

// Synchronous version
auto widget = find_widget(name);
auto success = widget.toggle();
if (!success) report_failure();

// Asynchronous version
find_widget(name).then([=](auto widget) {
    return widget.toggle();
}).then([=](auto success) {
    if (!success) report_failure();
});

Iteration is harder to convert to continuation-passing style because you need to restart the task chain, which means you have recursion.

Inside STL: The Different Types of Shared Pointer Control Blocks -- Raymond Chen

By Blog Staff | Oct 19, 2023 02:23 PM | Tags: None

In the realm of C++ standard library shared pointers, a crucial component for managing object lifetime is the control block, which contains reference count information and instructions for disposal and deletion. Depending on whether you use make_shared, allocate_shared, or manually assign an already-constructed pointer, different types of control blocks come into play, each with its own characteristics and optimizations for efficiently handling object management.

Inside STL: The Different Types of Shared Pointer Control Blocks

By Raymond Chen

From the article:

We saw earlier that C++ standard library shared pointers use a control block to manage the object lifetime.

struct control_block
{
    virtual void Dispose() = 0;
    virtual void Delete() = 0;
    std::atomic<unsigned long> shareds;
    std::atomic<unsigned long> refs;
};

The control block has pure virtual methods, so it is up to derived classes to establish how to dispose and delete the control block.

If you ask a shared_ptr to take responsibility for an already-constructed pointer, then you get this:

template<typename T>
struct separate_control_block : control_block
{
    virtual void Destroy() noexcept override
    {
        delete ptr;
    }
    virtual void Delete() noexcept override
    {
        delete this;
    }
    T* ptr;
};

SObjectizer Tales – 2. Can you call me back?--Marco Arena

By Marco Arena | Oct 19, 2023 01:36 AM | Tags: sobjectizer intermediate c++20

A new episode of the series about SObjectizer and message passing:

SObjectizer Tales – 2. Can you call me back

by Marco Arena

From the article:

A camera vendor has just released a new SDK that works through callbacks. Basically, the user sets a function that will get called by the SDK on every new available frame. How can we integrate this into a producer agent?

How to Use Monadic Operations for `std::optional` in C++23 -- Bartlomiej Filipek

By Blog Staff | Oct 17, 2023 02:19 PM | Tags: None

In this post we’ll have a look at new operations added to std::optional in C++23. These operations, inspired by functional programming concepts, offer a more concise and expressive way to work with optional values, reducing boilerplate and improving code readability.

How to Use Monadic Operations for `std::optional` in C++23

By Bartlomiej Filipek

From the article:

Let’s meet and_then(), transform() and or_else(), new member functions.

Traditional Approach with if/else and optional C++20  

In C++20 when you work with std::optional you have to rely heavily on conditional checks to ensure safe access to the contained values. This often led to nested if/else code blocks, which could make the code verbose and harder to follow.

Consider the task of fetching a user profile. The profile might be available in a cache, or it might need to be fetched from a server. Once retrieved, we want to extract the user’s age and then calculate their age for the next year. 

Phantom and Indulgent Shared Pointers -- Raymond Chen

By Blog Staff | Oct 13, 2023 02:12 PM | Tags: None

In our exploration of shared_ptr variations, we've previously covered cases where the stored pointer was either empty or pointed to a managed object. Now, we delve into the intriguing cases of phantom shared pointers, where the stored pointer is null but secretly manages an object, and indulgent shared pointers, which point to something but own nothing, offering unique utility for scenarios like static storage duration, with methods like use_count() and get() aiding in their detection.

Phantom and Indulgent Shared Pointers

By Raymond Chen

From the article:

Last time, we looked at various ways to convert among different shared_ptrs. We finished with this diagram:

You are familiar with an empty shared pointer, which manages no object and has no stored pointer. You are also familiar with a full shared pointer, which manages an object and has a non-null stored pointer (to the managed object, or something whose lifetime is controlled by the managed object). But what about those other two guys?

In the upper right corner, you have the case of a shared pointer that manages an object but whose stored pointer is null, which I’ve called a phantom shared pointer. If you convert the shared pointer to a bool, it produces false, because you can’t use it to access anything. The phantom shared pointer looks empty at a casual glance, but it secretly manages an object behind the scenes. That secretly-managed object remains alive for no visible reason. There is no way to access that secretly-managed object, but it’s still there. It’s a phantom which follows you around.