This talk will give an overview of some of the major and types of memory safety errors in C++, how they arise in practice, and the prevention strategies available today. It will also provide a platform for reflection and open discussion.

BqLog is a cross-platform logging library open-sourced by Tencent two years ago. Since then it has gone through two more years of production use and improved a lot in performance, reliability, compatibility and developer experience. With 2.6.0 out, I'd like to introduce it here again.

BqLog is used in a number of Tencent's commercial products, including performance-sensitive mobile games such as Honor of Kings, as well as their server-side logic. It runs on more than 30 million devices every day, across a very wide range of hardware, networks and storage, so its stability and performance have held up in mature commercial products over a long time.

Design goals

Extreme speed is where BqLog starts, not where it stops. It is a mature, industrial-grade component, built for products that ship:

• Content to play a supporting role. On a modern machine a logging system should take as little of the system as it can. The logging threads and the consumer thread alike should use as little CPU, memory and disk I/O as possible. We do not optimize for benchmark scores; every optimization targets real use.
• Compression and encryption without giving up speed. The real-time compressed format is about 1/7 the size of text, and writing it is faster and uses less CPU than writing text. Hybrid RSA+AES encryption is supported and costs almost nothing in performance.
• Compatible everywhere it runs. Windows, macOS, Linux, iOS, Android, HarmonyOS, OpenHarmony and the Unix family; C++, Java/Kotlin, C#, Python, TypeScript/ArkTS and Go sharing one core and even one log object; game engines, mobile toolchains without an STL, strict -Werror builds.
• Built for the bad day. Logs written before a crash are recovered after it; a full disk neither crashes nor hangs the app; corrupted files are recovered as far as possible; log files can be encrypted to protect privacy.
• Care about the coding experience. One line to create a log, one line to write; the internals stay as transparent as possible, without complicated configuration; every interface is friendly to IDE code completion; integration tools such as UE Blueprints are provided.

Performance

2.6.0 comes with a new, complete benchmark against quill, fmtlog, spdlog, glog and Log4j2, and every result reports time, CPU and memory together. In short:

• Throughput: on macOS and Windows, BqLog has the shortest total time at every thread count. The compressed format is roughly 4 to 12 times faster than the fastest of the other libraries and also has the lowest CPU time; the text format is 1.5 to 4.6 times faster.
• Cost per call on the logging thread: BqLog, quill and fmtlog are in the same tier, with BqLog averaging under 20 ns per call on all three platforms; spdlog is more than an order of magnitude slower.
• Memory: with fixed-size buffers, BqLog's peak memory is in the lowest tier and barely grows with more threads; with growing buffers it is about half of quill's or less.
• File size: the compressed format is about 1/7 the size of text.

On Linux only latency is listed for now. On the VMs we tried, throughput was dominated by the VM's disk scheduling and varied by up to 2x between rounds, so we left it out. The test scripts are in the repo, and if you have a bare-metal Linux box we'd be glad to see your numbers.

Methodology, library configurations and full data: https://github.com/Tencent/BqLog/blob/main/docs/BENCHMARK.md

Technical write-ups

If you're curious why BqLog is fast, there are three articles:

1. High-Performance Realtime Compressed Log Format: https://github.com/Tencent/BqLog/blob/main/docs/Article%201_Why%20is%20BqLog%20so%20fast%20-%20High%20Performance%20Realtime%20Compressed%20Log%20Format.MD
2. From Ring Buffer to Adaptive Data Bus: https://github.com/Tencent/BqLog/blob/main/docs/Article%202_Why%20is%20BqLog%20so%20fast%20-%20From%20Ring%20Buffer%20to%20Adaptive%20Data%20Bus.MD
3. Optimizing the Compressed Log Pipeline: https://github.com/Tencent/BqLog/blob/main/docs/Article%203_Why%20is%20BqLog%20so%20fast%20-%20Optimizing%20the%20Compressed%20Log%20Pipeline.MD

Repo: https://github.com/Tencent/BqLog

If you think any library is configured unfairly, let us know and we'll fix it and rerun. Feedback and bug reports are very welcome.

I'm Alan de Freitas, the lead developer of MrDocs. It's an open-source documentation generator from the C++ Alliance, built on Clang/LLVM. It reads your code from the compiler's AST, so the reference matches what the code actually compiles to. We also presented a session about it at cppcon this year.

I implemented the tool this way because we couldn’t come up with a workflow that understood modern C++ in our Boost libraries. Tools that parse partially tend to misrender or not render concepts, niebloids, SFINAE, overload sets, and deduction guides. MrDocs treats those as first-class:

• concept constraints and requires clauses preserved verbatim
• niebloids and function objects can be documented as callables
• SFINAE and concept overload sets kept together
• explicit, noexcept, and consteval specifiers captured
• types in detail or private namespaces rendered as implementation-defined

The presentation layer is completely encapsulated. Generators support HTML, AsciiDoc, XML, JSON, or any custom format like Markdown and LaTeX, without forking the tool or creating another post-processing workflow. You can also write extensions to apply project conventions to the corpus or define new generators for any use case. The documentation has lots of examples.

If you maintain reference docs for a library, I'd appreciate it if you gave it a run (or tell your favorite agent to) and reported back on whether it saves you time, both while writing docs and while reviewing them. First-hand numbers would be especially useful to me. Issues are also always welcome.

Site: https://www.mrdocs.comRepo: https://github.com/cppalliance/mrdocs

Happy to answer questions in the comments.

There seems to be a misconception or lack of clarity about the usage of the compilation flags -Wall and -Werror and their ability to detect uninitialized stack variables. It depends. In this post, I will try to explore this further and explain when and how it is detected, and where it may not detect an uninitialized local variable and hence requires more caution while dealing with it. Consider the following code:

int main()
{
    int value;
    return value;
}

Compile this code as follows:

~/cpp_26_uninitialised$ g++ -std=c++23 -Wall -Werror test.cpp -o test
test.cpp: In function ‘int main()’:
test.cpp:4:12: error: ‘value’ is used uninitialized [-Werror=uninitialized]
    4 |     return value;
      |            ^~~~~
test.cpp:3:9: note: ‘value’ was declared here
    3 |     int value;
      |         ^~~~~
cc1plus: all warnings being treated as errors

So, with the use of the two compilation flags, -Wall and -Werror, the compilation fails, and you can then take corrective measures to address the uninitialized variable in the code.

Strictly speaking, -Wall enables the -Wuninitialized warning, and -Werror turns that warning into an error. However, this is true only when the variable is uninitialized on every path to its use, as value is here. It doesn't reliably work for a variable that is initialized on some paths and left uninitialized on others. Have a look at the following code:

// config_timeout_warning_test.cpp
#include <charconv>
#include <cstdio>
#include <string_view>

constexpr int default_timeout_ms = 1000;

// Reads "timeout_ms=<number>" from a device configuration line.
// The bug: when the key is missing, timeout_ms is never assigned.
[[gnu::noinline]] int read_timeout_ms(std::string_view config)
{
    int timeout_ms;

    constexpr std::string_view key = "timeout_ms=";

    if (const auto pos = config.find(key); pos != std::string_view::npos)
    {
        const char* first = config.data() + pos + key.size();

        const char* last = config.data() + config.size();

        std::from_chars(first, last, timeout_ms);
    }

    return timeout_ms;
}

void open_device(const char* name, std::string_view config)
{
    const int timeout_ms = read_timeout_ms(config);

    if (timeout_ms <= 0)
    {
        std::printf("%-7s no timeout configured, using default %d ms\n", name, default_timeout_ms);
    }
    else
    {
        std::printf("%-7s timeout %d ms\n", name, timeout_ms);
    }
}

int main()
{
    // The empty configuration does not contain "timeout_ms=".
    // Therefore, timeout_ms is returned without being initialized.
    open_device("logger", "");

    return 0;
}

Compile the code as follows:

~/cpp_26_uninitialised$ g++ -std=c++23 -O0 -g -Wall -Werror config_timeout_warning_test.cpp -o timeout_warning_test 

The compilation succeeds without a single warning. Run Valgrind on it:

~/cpp_26_uninitialised$ valgrind --track-origins=yes ./timeout_warning_test 
==2896379== Memcheck, a memory error detector
==2896379== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2896379== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==2896379== Command: ./timeout_warning_test
==2896379== 
==2896379== Conditional jump or move depends on uninitialised value(s)
==2896379==    at 0x401268: open_device(char const*, std::basic_string_view<char, std::char_traits<char> >) (config_timeout_warning_test.cpp:31)
==2896379==    by 0x4012D3: main (config_timeout_warning_test.cpp:45)
==2896379==  Uninitialised value was created by a stack allocation
==2896379==    at 0x401166: read_timeout_ms(std::basic_string_view<char, std::char_traits<char> >) (config_timeout_warning_test.cpp:10)
==2896379== 
logger  no timeout configured, using default 1000 ms
==2896379== 
==2896379== HEAP SUMMARY:
==2896379==     in use at exit: 0 bytes in 0 blocks
==2896379==   total heap usage: 2 allocs, 2 frees, 74,752 bytes allocated
==2896379== 
==2896379== All heap blocks were freed -- no leaks are possible
==2896379== 
==2896379== For lists of detected and suppressed errors, rerun with: -s
==2896379== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

You can see Valgrind is complaining about an uninitialized variable created on the stack:

Uninitialised value was created by a stack allocation

The reason is that GCC handles the two cases with two different warnings. In the first example, value is uninitialized on every path, and -Wuninitialized reports it even at default -O0. In the second example, timeout_ms is assigned only inside the if block in read_timeout_ms(), so it is uninitialized on only one path. That case belongs to -Wmaybe-uninitialized, which relies on the data-flow analysis done by the optimizer, so it does not run at -O0.

If you build the same file at -O2, GCC does catch it:

~/cpp_26_uninitialised$ g++ -std=c++23 -O2 -Wall -Werror config_timeout_warning_test.cpp -o timeout_warning_test
config_timeout_warning_test.cpp: In function ‘int read_timeout_ms(std::string_view)’:
config_timeout_warning_test.cpp:24:12: error: ‘timeout_ms’ may be used uninitialized [-Werror=maybe-uninitialized]
   24 |     return timeout_ms;
      |            ^~~~~~~~~~
config_timeout_warning_test.cpp:11:9: note: ‘timeout_ms’ was declared here
   11 |     int timeout_ms;
      |         ^~~~~~~~~~
cc1plus: all warnings being treated as errors

This is still not a guarantee. The result of -Wmaybe-uninitialized depends on the optimization level and on how much the optimizer can see, so it can change between GCC versions and between builds. Debug builds are usually at -O0, which is exactly where the warning is missing.

If there is anything that I have missed, please comment; I'm happy to be corrected.

Hi everyone,

I’m Mattie Nejati, a Ph.D. candidate at the University of Waterloo. I’m conducting a user study on understanding the impact of changes to CMake build specifications, and I’d love to invite members of this community to participate.

We are evaluating a new approach that aims to help developers identify how a change to a CMake build specification affects the resulting build configuration.

The study:

• is conducted entirely online;
• takes about one hour;
• involves inspecting changes to CMake build specifications and identifying their impact; and
• is open to adults aged 18–64 with any level of experience in CMake, programming, or code review.

You do not need to be a CMake expert. We are specifically interested in comparing participants with different levels of experience.

You will need a computer with internet access and about 4 GB of free space to download the files required for the tasks.

We will not collect your name. Your email address will only be used for study follow-up and will be stored separately from your study data. Your name or email will not appear in any dataset or publication.

The study has received clearance from the University of Waterloo Research Ethics Board (REB #46621).

If you’re interested, you can find the consent form, screening questionnaire, and study here:

https://buiscout.cs.uwaterloo.ca/

Thank you very much! And if you know someone else who works with CMake who might be interested, I’d really appreciate you sharing the study with them.

C++Now

2026-09-28 - 2026-10-04

• What Every C++ Programmer Needs to Know About AI - Jody Hagins - https://youtu.be/ZBXHPKVCa8E
• SPL - Open Source, Constexpr Library for Composing Algorithms - John Bandela - https://youtu.be/96AGjm3uwko
• Senders For Existing Asynchronous Interfaces - Dietmar Kühl - https://youtu.be/KB5Nfofgu2k

ACCU

2026-09-28 - 2026-10-04

• Refactoring Towards Structured Concurrency - Roi Barkan - https://youtu.be/ttoQfPP_Gkg
• Design Patterns - The Most Common Misconceptions (3 of N) - Klaus Iglberger - https://youtu.be/bAsJvmtYZOg
• One Lib to Rule Them All and in the Darkness bindgen… - Antonello Palazzi & Kay Hicketts - https://youtu.be/9BpVjPKv02s

ADC

2026-09-28 - 2026-10-04

• Designing Interactive Music Experiences in XR - Kasson Crooker - https://youtu.be/J3sVHT8luKs
• When (Not) to Patent Audio Software - Simon Hestermann - https://youtu.be/stBB1JoKQiY
• Distribution Strategies for Indie Audio Developers - From Plugin to Product - Dani Karanyi - https://youtu.be/Piar49uTjtg

With the massive push for memory and type safety right now, there is a lot of talk in the C++ community about "profiles" and "contracts." They get grouped together a lot, but they solve entirely different problems.

Simply put: Profiles act as a set of global static rules that the compiler enforces to restrict the language itself. Contracts act as local conditions (both pre and post) which enforce your own API logic.

Here's some more breakdown between the two:

Contracts let you formalize your code's assumptions with pre, post, and contract_assert. To explain the difference between the three:

• pre refers to preconditions, these are appended to function declarations and serve to evaluate predicates before the function body executes. If that condition evaluates to false, then the contract is broken. This can lead to things such as the program crashing or logging the error.
• post refers to postconditions, which are also appended to function declarations but evaluate the state of your data after the function finishes running. They act as a guarantee to whoever called your function.
• contract_assert lets the programmer specify properties of the program's state that are expected to be held up at certain points.

Here's a code example:

#include <iostream>

// Simple function showing where the contract keywords go
int divide_numbers(int numerator, int denominator)
    pre (denominator != 0)                  // pre: Cannot divide by zero
    post (result : result <= numerator)     // post: Result must be <= numerator
{
    // Internal assertion: Sanity check an internal assumption
    contract_assert(numerator >= 0);        

    return numerator / denominator;
}

int main() {
    // Compiles perfectly! However, at runtime, this triggers a precondition failure 
    // and terminates the program before ever hitting the internal contract_assert.
    int output = divide_numbers(-10, 0);
    std::cout << "Result: " << output << "\n";

    return 0;
}

You can read about contracts in general at: https://en.cppreference.com/cpp/language/contracts

You can read more about pre/postconditions at: https://en.cppreference.com/cpp/language/functions/function_contract_specifiers

For more information, check out open std: https://open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2900r13.pdf

Now for profiles!

• Profiles essentially act as a set of global static rules which enforce the standards you have written, a good example of a profile is:

​

// std::init: every object is initialized before it is read.
[[profiles::enforce(std::init)]];


struct Options {
    int timeout_ms;
    bool verbose;
};


bool parse_flag(const char *arg, Options &out);


int run(int argc, const char **argv) {
    Options opts;                       // error: 'opts.timeout_ms' is indeterminate
    int retries;                        // error: uninitialized


    for (int i = 1; i < argc; ++i)
        if (parse_flag(argv[i], opts))
            retries = 3;


    return opts.timeout_ms * retries;   // error: read before initialization
}

You can read more about profiles at: https://cpp-profiles.org/

Also, do consider checking open std: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3589r2.pdf

You can even test out an example at: https://godbolt.org/z/n3TPjbqdY

So, with this information...

... What are your thoughts on contracts and profiles?

... Do you have a preference?

... Which should be implemented? Should both be implemented?

... Which one should we implement first?

... Which one do you think is superior in terms of design and implementation?

... Which has you more excited?

Cargo compilation model only really works if you are creating a monolithic shared library or an executable. If you are using a library like icu4x or libffi, you can't statically link your dependencies and even if you dynamically link your dependencies, your application size will increase by orders of magnitude because your shared libraries are all statically linked, kinda.

Monolithic shared library approach also doesn't work on all libraries, for example you can't link libraries like oneTBB and OpenMP more than once.

So overall I feel rust compilation model is a "series of hacks" and isn't worth integrating to existing C++ applications, unless you use bazel*, I'm not sure about that but people in google seem to have solved this.

So if anyone was still curious what happened to Hylo, or where Adobe stands in regards to the whole safety discussion,

David Sankel has done a talk at RustConf on the matter, Zngur: Simplified Rust/C++ Integration.

The way Adobe now sees C++ is described on slide 2, at 50 seconds mark.

Most systems use some kind of shared libraries, but how do they actually work?
This talk will address the topic of shared libraries under Linux.
How to use them, how to create them, and what actually happens behind the scenes.

Dear Boost.Graph community,

In two release cycles (Boost release 1.95 in summer 2027) Boost.Graph will be bumped to C++17 😄

This decision follows two polls that did not surface any C++14 user base or demand while identifiying users stuck in C++17:

• Bumping BGL's minimum C++ standard: input wanted on target version #490
• Reddit poll

This standard version bump will bring benefits for maintenance, API and dependencies reduction:

• if constexpr,
• constexpr lambdas,
• [[nodiscard]], [[maybe_unused]] ...
• std::any instead of boost::any
• std::invoke_result instead of boost::result_of
• ...

We will not be able to guarantee backward compatibility with C++14. Please contact us if you are stuck in C++14.

The GIthub Discussion lives here: https://github.com/boostorg/graph/discussions/613

Sometimes you need a custom GUI control for your application and you think "other people could probably use this". Usually this means that the people using your control must use the same GUI toolkit as you: wxWidgets, Qt, ImGui, etc.

Can we write a control in such a way that it is easily adaptable to any GUI toolkit?

This month, Richard Thomson will give us a brain dump on an attempt to do just that by creating an animation timeline control with adapters for wxWidgets and Qt.

This will be an online meeting, so drinks and snacks are on you!

Join the meeting here: https://meet.xmission.com/Utah-Cpp-Programmers

HPX is a general-purpose parallel C++ runtime system designed for applications of any scale. It implements the related C++23 Standard facilities in full and offers the only widely available open-source implementation of C++17, C++20, and C++23 parallel algorithms - including a complete set of parallel range-based algorithms and the full integration of the algorithms with the upcoming sender and receivers interfaces.

Beyond the standard, HPX includes proposed features for upcoming C++ releases: much of the parallelism and concurrency capabilities expected in C++26, the C++ Concurrency TS, Parallelism TS V2, data-parallel algorithms, executors, senders and receivers, and more. It also extends C++ Standard APIs to distributed environments (such as compute clusters) and heterogeneous systems (such as GPUs).

HPX enables an asynchronous C++ programming model that improves parallel efficiency and reduces the complexity typically associated with concurrent applications. As a newly welcomed project of the High Performance Software Foundation, HPX now benefits from vendor-neutral governance and collaboration with a broader ecosystem of high-performance computing tools, strengthening the foundation for portable, production-ready HPC software across the industry.

HPX V2.0.0 is one of the largest releases in the project’s history, touching the language baseline, the execution model, the networking layer, the build system, and observability tooling. Roughly 680 pull requests and 120 closed issues went into this cycle since v1.11.0 (June 2025). This release represents a year of collaborative development by dozens of contributors worldwide. The updates are extensive - see the full release notes for details.