How Can I Prevent Myself From Using a Parameter After I’ve Extracted All Value? -- Raymond Chen

By Blog Staff | Dec 18, 2023 04:27 PM | Tags: None

Imagine you have a function parameter that you want to protect from direct access, ensuring that all future interactions occur through a wrapper or transformation. This situation often arises in scenarios like implementing a logging wrapper for a class. In this discussion, we'll explore a clever technique known as "hide_name" to achieve this goal, allowing you to enforce the use of the wrapper and prevent direct access to the parameter.

How Can I Prevent Myself From Using a Parameter After I’ve Extracted All Value From It?

By Raymond Chen

From the article:

Suppose you have a function that takes a parameter that you want to transform in some way, and you want to require that all future access to the parameter be done through the transformed version. One example is a wrapper class that does logging.¹

struct WidgetRefWrapper
{
    WidgetRefWrapper(
        Widget& widget,
        Logger& logger) :
    m_widget(widget), m_logger(logger) {}
    
    void Toggle() try
    {
        m_logger.Log("Toggling the widget");
        m_widget.Toggle();
        m_logger.Log("Toggled the widget");
    } catch (...) {
        m_logger.Log("Exception while toggling the widget");
        throw;
    }

private:
    Widget& m_widget;
    Logger& m_logger;
};

void DoSomething(Widget& widget)
{
    Logger& logger = GetCurrentLogger();
    WidgetWrapper wrapper(widget, logger);

    // Do not use the widget directly!
    // Always use the wrapper!

    if (needs_toggling) {
        wrapper.Toggle();
    }
}

You want that “Do not use the widget directly!” comment to have some teeth. Can you “poison” the widget parameter so it cannot be used any more?

6 impossible things - Kevlin Henney - Opening Keynote Meeting C++ 2023

By Meeting C++ | Dec 17, 2023 02:24 PM | Tags: meetingcpp intermediate advanced

Kevlin Henney gave the opening keynote at Meeting C++ 2023

6 impossible things - Kevlin Henney - Opening Keynote Meeting C++ 2023

by Kevlin Henney

Video:

2023-12 Mailing Available

By Administrator | Dec 16, 2023 06:04 PM | Tags: None

The 2023-12 mailing of new standards papers is now available.

SObjectizer Tales – 10. Handling GUI from main--Marco Arena

By Marco Arena | Dec 14, 2023 02:04 AM | Tags: sobjectizer intermediate c++20

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

SObjectizer Tales – 10. Handling GUI from main

by Marco Arena

From the article:

In this episode, we discuss how to test message passing-styled applications and provide some examples on our project.

Striving For Better C++ Code, Part I: Data Flow Analysis Basics -- Anastasia Kazakova

By Blog Staff | Dec 11, 2023 04:28 PM | Tags: None

We’ll look at the basics of data flow analysis, including how it works in general, while presenting several real-world examples where it can help you write better code.

Striving For Better C++ Code, Part I: Data Flow Analysis Basics

by Anastasia Kazakova

From the article:

All data flow inspections rely on the control-flow graph. This is a graph on which vertices are the statements in the program and edges are the control flow jumps between these statements (direct code execution, conditional jumps, loops, breaks, gotos, etc.).

For example, the control-flow graph at the right represents the function foo on the left:

SObjectizer Tales – 9. Splitting work--Marco Arena

By Marco Arena | Dec 7, 2023 01:28 AM | Tags: sobjectizer intermediate c++20

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

SObjectizer Tales – 9. Splitting work

by Marco Arena

From the article:

In this episode we'll delve into the fundamental way for dividing a task among several agents.

How to use std::span from C++20 -- Bartlomiej Filipek

By Blog Staff | Dec 4, 2023 11:00 AM | Tags: None

In this article, we’ll look at std::span which is more generic than string_view and can help work with arbitrary contiguous collections.

How to use std::span from C++20

by Bartlomiej Filipek

From the article:

Here’s an example that illustrates the primary use case for std::span:

In traditional C (or low-level C++), you’d pass an array to a function using a pointer and a size like this:

void process_array(int* arr, std::size_t size) {
  for(std::size_t i = 0; i < size; ++i) {
    // do something with arr[i]
  }
}

std::span simplifies the above code:

void process_array(std::span<int> arr_span) {
  for(auto& elem : arr_span) {  
    // do something with elem  
  } 
} 

The need to pass a separate size variable is eliminated, making your code less error-prone and more expressive.

SObjectizer Tales - 8. Representing errors--Marco Arena

By Marco Arena | Nov 30, 2023 12:06 AM | Tags: sobjectizer intermediate c++20

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

SObjectizer Tales - 8. Representing errors

by Marco Arena

From the article:

In this episode we'll discuss how to model application errors and explore techniques for filtering messages within agents!

Enodo, Divide et Impera -- Lucian Radu Teodorescu

By Blog Staff | Nov 29, 2023 10:55 AM | Tags: None

How do you untie the knotty problem of complexity? Lucian Radu Teodorescu shows us how to divide and conquer difficult problems.

Enodo, Divide et Impera

By Lucian Radu Teodorescu

From the article:

This article aims to analyse one of the most useful techniques in software engineering: the divide et impera (Divide and Conquer) technique. And maybe the most useful one.

We define the divide et impera method as a way of breaking up a problem into smaller parts and fixing those smaller parts. This applies to recursive functions (where the phrase divide et impera is most often used), but it will also apply to the decomposition of problems. At some point, we will also discuss using abstraction as a way of applying divide et impera. Finally, we will show how to use this technique in our daily engineering activities that are not strictly related to coding.

In this article, we call divide et impera a method of approaching problems that has the following characteristics:

• breaking the problem into sub-problems
• solving the sub-problems independently of each other
  • occasionally, an answer to a sub-problem may render solving the rest of the sub-problems unnecessary
  • sporadically, a small amount of information passes one sub-problem to another
• combining the results of the sub-problem solutions to form the solution to the initial problem

Live and Let Die -- Martin Janzen

By Blog Staff | Nov 25, 2023 10:49 AM | Tags: None

Resource lifetime management can be problematic. Martin Janzen reminds us how important destructors are and when to be mindful of their limitations.

Live and Let Die

By Martin Janzen

From the article:

Most experienced C++ programmers will agree that one of the best properties of our language is the ability to manage object lifecycles using constructors and destructors.

Bjarne Stroustrup [Stroustrup19] has described ctor/dtor pairs as one of C++’s most elegant features, giving us the ability to create clean types which tidy up after themselves, with predictable performance, minimal overhead, and no need for garbage collection.

In this year’s ACCU Conference Lightning Talks, Nico Josuttis singled out destructors as (spoiler alert!) “the most important C++ feature” [Josuttis23]; and Wiktor Klonowski told a sad tale of time wasted debugging a .NET program that kept running out of ports, a fate which could have been avoided by the use of dtors [Klonowski23].

At the same conference, as well as at the recent C++ On Sea, numerous speakers talked about C++ and safety, a subject that’s been very much in the news recently [NSA22], with C++ predictably receiving a lot of flak for the ease with which one can write code containing buffer overflows, memory leaks, and of course a rich and varied choice of ways to introduce undefined behaviour (UB).

In its favour, though, C++ also provides at least one way in which we can improve safety, and reliability, greatly, by use of the powerful RAII (Resource Acquisition is Initialisation) idiom: taking ownership of a resource in the ctor, then releasing it in the dtor.