Home » Blog » 2023 » December

December 2023

Releasing the keynotes of Meeting C艹 2023

By Meeting C艹 | Dec 30, 2023 03:38 AM | Tags: performance meetingcpp intermediate community C艹20 C艹17 C艹14 basics advanced

Highlighting the current video releases for Meeting C艹 2023: the keynotes

With this year Meeting C艹 had a unique set of keynotes, covering 6 impossible problems for software devs with the opening keynote by Kevlin Henney, followed by great wisdom about how open communities thrive by Lydia Pintscher. The closing keynote by Ivan Čukić was an impressive medley composing various idioms with Prog(ressive) C艹.

All these keynotes are worth watching, a great contribution to our knowledge base as a community. Thanks to Kevlin Henney, Lydia Pintscher and Ivan Čukić for preparing these great presentations!

Boost 1.84.0 has been released

By Blog Staff | Dec 28, 2023 01:26 PM | Tags: None

space.pngspace.pnggetboost.pngRelease 1.84.0 of the Boost C艹 Libraries is now available.

These open-source libraries work well with the C艹 Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use.

Release 1.84.0 contains two new libraries and numerous enhancements and bug fixes for existing libraries.

New Libraries

  • Cobalt: Basic algorithms and types for C艹20 coroutines, from Klemens Morgenstern.
  • Redis: Redis async client library built on top of Boost.Asio, from Marcelo Zimbres Silva.

Here are some useful links for 1.84.0.


Marshall Clow and Glen Fernandes managed this release - we very much appreciate their continued hard work!

C艹20, Spans, Threads and Fun -- Bartlomiej Filipek

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

C艹20_Spans_Threads_and_Fun.pngIn this post, we’ll have fun using C艹20’s spans to process data on multiple threads. What’s more, we’ll be equipped with the latest concurrency features from C艹20.

C艹20, Spans, Threads and Fun

by Bartlomiej Filipek

From the article:

Our task is relatively simple but can be extended to various multi-phase computations.

We need to initialize a container with numbers, filter them, then build a histogram.

Here’s the overview of the process:

CLion Nova Explodes onto the C and C艹 Development Scene -- Anastasia Kazakova

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

clionnova.pngWe’re announcing a free early preview of CLion, which uses the ReSharper C艹/Rider C艹 language engine instead of the CLion "legacy" engine. The Preview build is available via our dedicated Toolbox App feed. At some point in 2024, depending on the results of the feedback collected, CLion Nova will be merged into CLion. Until then, the Preview build will be free to use and can be installed in parallel with your usual CLion (Classic) installation.

CLion Nova Explodes onto the C and C艹 Development Scene

by Anastasia Kazakova

From the article:

The first C艹 engine by JetBrains was designed for AppCode, our IDE for iOS and macOS developers. It was part of the IntelliJ Platform, initially written in Java and later also in Kotlin. The approach and the architecture of the engine serve many languages in IntelliJ-based IDEs well; however, this design turned out not to be the best fit for the C艹 language specifically.

To more quickly align with the evolution of C艹 and to separate the engine and IDE processes, a clangd-based engine was later added to CLion. Built on our custom branch of clangd, this engine detects any warnings and errors, shows them in the editor, and suggests quick-fixes, as well as performing highlighting, completion, and certain navigation actions. It’s also used for things like data flow analysis and MISRA checks. Meanwhile, CLion’s “legacy” engine is responsible for other code insight features like refactorings. You can see a detailed “list of responsibilities” in our CLion documentation.

Top 10 errors in C and C艹 projects in 2023

By Andrey Karpov | Dec 22, 2023 05:26 AM | Tags: pvs-studio

New Year is coming! It means, according to tradition, it's time to recall 10 of the most interesting bugs that PVS-Studio found during 2023.

Top 10 errors in C and C艹 projects in 2023

by Alexey Gorshkov

From the article:

In this case, the developers wanted to fill the keyEventList array with zeros. Pay attention to the third parameter — the number of bytes the developers wanted to fill with zeros. In this case, sizeof(keyEventList) evaluates the pointer size instead of the array size. It depends on the target platform, but most often it's 4 or 8 bytes. However, the size of the structure is clearly larger than 4 or 8 bytes.

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?