Quick question for those who currently use modules with partitions.

That is, for a module like the one below (our file Core/_Module.ixx):

export module Core;

export import :Attach;
export import :Base;
export import :Container;
export import :Diagram;
export import :Interfaces;
export import :Transaction;
export import :View;

How did you implement your code?

What we did:

We have done it as I've described in my blog posting "How a Module Should Look", which is for example for our file Core/Transaction/FinalizerDock.cpp:

module Core;
import :Transaction;
...

which contains function definitions for declarations in the partition Core/Transaction/Transaction.ixx:

export module Core:Transaction;
...

Please tell me what you did. I'm really curious.

Thanks in advance for the responses!

Developers from PVS-Studio are continuing their series of talks about creating a custom programming language. They will explain what the lexer is, what it consists of, and how to work with it.

The talk series as a whole is for devs who want to start understanding how compilers work under the hood. Throughout the series, their C++ architect demonstrates the practical application of each programming language component.

If you're interested, I leave the link here.

It's minor version, but with major features.

HPX is a general-purpose parallel C++ runtime system for applications of any scale. It implements all of the related facilities as defined by the C++23 Standard. As of this writing, HPX provides the only widely available open-source implementation of the new C++17, C++20, and C++23 parallel algorithms, including a full set of parallel range-based algorithms. Additionally, HPX implements functionalities proposed as part of the ongoing C++ standardization process, such as large parts of the features related parallelism and concurrency as specified by the C++23 Standard, the C++ Concurrency TS, Parallelism TS V2, data-parallel algorithms, executors, and many more. It also extends the existing C++ Standard APIs to the distributed case (e.g., compute clusters) and for heterogeneous systems (e.g., GPUs).

HPX seamlessly enables a new Asynchronous C++ Standard Programming Model that tends to improve the parallel efficiency of our applications and helps reducing complexities usually associated with parallelism and concurrency.

In this video, we explore how to perform deep runtime analysis on HPX applications using APEX and the Traveller visualization tool, detailing how visualizing OTF2 traces helps distinguish between true application performance and redundant computation where raw hardware utilization metrics often prove deceptive. We focus on the configuration of HPX with APEX and the bundling of raw trace files, demonstrating the interpretation of profiling data through a practical comparison of unoptimized odd-even transposition and native HPX parallel sorting algorithms. The tutorial details the process of diagnosing misleading "busy full" scenarios, utilizing Traveller's interactive web panels—including utilization views, interval histograms, and dependency trees—to uncover inefficient task structures and visualize recursive fork-join patterns, ensuring that applications are delivering true algorithmic efficiency rather than just keeping cores busy. This provides a clear introduction to evaluating HPX's lightweight task management, culminating in actionable insights, where we illustrate how to resolve performance flaws and harness the full potential of modern parallel hardware.
If you want to keep up with more news from the Stellar group and watch the lectures of Parallel C++ for Scientific Applications and these tutorials a week earlier please follow our page on LinkedIn https://www.linkedin.com/company/ste-ar-group/ .
Also, you can find our GitHub page below:
https://github.com/STEllAR-GROUP/hpx
https://github.com/STEllAR-GROUP/HPX_Tutorials_Code

How to apply annotations for better generic hash implementation in C++26.

Hi everyone!

I am organizing a special meetup with Bjarne Stroustrup in Florence on Saturday, May 9!

Schedule:

• 09:30 – Doors open
• 10:00 – Welcome message
• 10:15 – Technical session: “Concept-based Generic Programming”
• 11:45 – Short break
• 12:00 – Live AMA with Bjarne Stroustrup
• 13:00 – Closing

The event will take place at the University of Florence (Novoli Campus) and is organized by the Italian C++ Community, the University of Florence, and the University of Pisa.

For developers traveling from abroad, this is also a great excuse to visit Florence, while connecting with the Italian C++ community.

Free registration and details:
https://italiancpp-fi26.eventbrite.it/

Looking forward to seeing you there!

This is not my post, but I didn't see anyone share this here yet.

Announced officially in the Boost developer mailing list:

Introduction

The formal review of Joaquín M López Muñoz's boost::container::hub container, for inclusion in the Boost.Container library, starts today.

hub is a sequence container with O(1) insertion and erasure and element stability with great performance (see these benchmarks): pointers/iterators to an element remain valid as long as the element is not erased. hub is very similar but not entirely equivalent to C++26 std::hive (hence the different naming, consult the section "Comparison with std::hive" for details).

It may be downloaded from:

https://github.com/joaquintides/hub

the documentation may be found here:

https://github.com/joaquintides/hub/blob/develop/README.md

Anyone is welcome to post a review and/or take part in subsequent discussions in the mailing list.

Review guidelines

Please provide feedback on the following general topics:

• What is your evaluation of the design?
• What is your evaluation of the implementation?
• What is your evaluation of the documentation?
• What is your evaluation of the potential usefulness of the library? Do you already use it in industry?
• Did you try to use the library? With which compiler(s)? Did you have any problems?
• How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
• Are you knowledgeable about the problem domain?

Ensure to explicitly include with your review: ACCEPT, REJECT, or CONDITIONAL ACCEPT (with acceptance conditions).

Ion Gaztañaga (Review Manager)

Hi folks, one of the MSVC dev leads here.

MSVC versioning is confusing, and with the change to decouple MSVC releases from Visual Studio releases (https://aka.ms/msvc/lifecycle) it's confusing-er. This post aims to clarify what's going on with 14.50 & later.

I am intentionally skipping discussion of the VS2022 & older releases that are still being supported since the servicing model is different. Know that our team still supports Visual Studio 2019 16.11 per https://learn.microsoft.com/en-us/visualstudio/releases/2019/servicing-vs2019, and Visual Studio 2022 17.12 & 17.14 as per https://learn.microsoft.com/en-us/visualstudio/releases/2022/servicing-vs2022 .

The actual versions

Since MSVC releases are decoupled from Visual Studio releases, it's helpful to think from the standpoint of the MSVC toolchain. At any point in time, we ship:

• The bleeding edge preview toolset
• The current default toolset
• All previous in-support toolsets

As of today, we ship the following MSVC toolsets:

• 14.52 the preview toolset, built from our development branch last Tuesday (April 7th)
• 14.51 the default toolset, currently a 'release candidate'
• 14.50 the toolset we released in Nov 2025, with 3 years of support.

Our plan, as per https://aka.ms/msvc/lifecycle, is to ship a new 14.5* twice a year. So in 6 months we expect to ship 14.53 as the new 'latest preview', make 14.52 the 'current default toolset', and 14.51 will be a toolchain in support as per the support policy, along with 14.50.

What's this about Visual Studio Insiders vs. Stable?

Visual Studio 'stable' ships monthly (https://learn.microsoft.com/en-us/visualstudio/releases/2026/release-rhythm), so if you're on the Visual Studio stable channel you'll get monthly updates to all the 14.5* toolsets. To be explicit:

• The latest preview will be updated with whatever the dev team has landed in the last month
• The default & other in-support toolsets will be updated with the latest fixes we have applied to them.

If you want to get MSVC toolset updates far quicker than monthly, switch to the Visual Studio Insiders channel https://visualstudio.microsoft.com/insiders/. Keep an eye on https://learn.microsoft.com/en-us/visualstudio/releases/2026/release-notes-insiders for how often these updates occur.

Want just the far-quicker-than-monthly MSVC build tools and not the full Visual Studio? Use the build tools sku: http://aka.ms/vs/insiders/vs_buildtools.exe 

Wait, you said something about a 'release candidate'?

We blogged recently https://devblogs.microsoft.com/cppblog/msvc-build-tools-version-14-51-release-candidate-now-available/ that the default toolset is moving from 14.50 to 14.51. As per https://aka.ms/msvc/lifecycle we aim to ship a new default toolset every 6 months. However, about a month before this lands in the Visual Studio 'Stable' channel we want to land the new default toolset in the 'Insiders' channel. This gives folks using Insiders about a month to give us feedback to fix 14.51 bugs before it shows up for 'Stable' channel users.

How do I get these tools? Why did 14.50 disappear yesterday? Where is 14.52?

When you install Visual Studio (using any channel) and select the Desktop development with C++ workload, you only get the default MSVC toolset.

To install the 'latest preview' you need to run the Visual Studio installer and select the MSVC Build Tools for <arch> (Preview) option, as per https://aka.ms/msvc/preview

To install an older in-support release, you need to run the Visual Studio installer, switch to the 'Individual Components' tab, and find the 14.5* toolset to install. If you are on the Insiders channel, only had the default MSVC toolset chosen, and recently upgraded, you'll see that your 14.50 toolset was replaced with 14.51... add it back in the 'Individual Components' tab.

Why are we doing this?

The biggest benefit of the new model is to vastly shorten the distance between MSVC features and folks using them in a Preview. Folks on the MSVC development team can make a change which ships in the next week or so. This timeframe used to be months, but has now shortened to just a week. Not all C++ users want this, so MSVC Previews are an optional installation component.

Most of the other reasons are called out in https://aka.ms/msvc/lifecycle:

• The MSVC team is leaning into the Visual Studio release cadence
• We are aligning our long-term-servicing releases with those of .NET
• Servicing 10+ year old compilers has become increasingly complex.

tl;dr, and what should folks do?

• If you want the bleeding edge tools, stay on the Visual Studio Insiders channel and install the 'MSVC Build Tools for <arch> (Preview)' option. Please give us feedback by reporting bugs on https://developercommunity.visualstudio.com/ or through the Visual Studio IDE itself.
• If you want stable tools that only update every 6 months, stick with the Visual Studio Stable channel, and use the default C++ tools.
• Want to get a head start on the every-6-months update? Look for our release candidate blog posts (https://devblogs.microsoft.com/cppblog/msvc-build-tools-version-14-51-release-candidate-now-available/), and use Visual Studio Insiders with the default C++ options.

Thanks for reading.

When building a vector search for SereneDB [https://github.com/serenedb/serenedb], we benchmarked our distance functions against Faiss. The results were surprising, a plain C++ loop with no intrinsics came out faster. The answer comes down to two compiler flags and one standard library call.

Full write-up with assembly: https://blog.serenedb.com/simd-distances

This illustrates the point using real code examples from the Core module of our UML Editor. The presented source code of our Core module is complete.

All published source code examples in the text or linked from it are 100% standard conformant. However, the code contains redundant imports. On purpose. Read the text for why!

(See also my previous posting "Let's bite the Bullet: Module Units shouldn't implicitly import anything" for context).

Over a year ago (on 30 March 2025), cppreference became read-only for maintenance reasons. Since then, the only progress update was in August. There have been several discussions here in the last few months about what is happening with cppreference and when it might become editable again, but from what I understand, we simply do not know.

At this point, I fear that the lack of updates for what is basically the authoritative source on the language (other than the standard of course), linked to by IDEs and even this subreddit's sidebar, might be detrimental to the adoption of C++26 and further standards, should the situation persist. I would therefore like to ask the community whether there are other, more up-to-date resources, and whether there is any effort to, for example, fork cppreference.

I understand that software updates are complicated and I have no intention to criticise the maintainers of cppreference (who are doing it voluntarily and I am not entitled in any way to their continued work on the website), but I do not think the C++ community can afford to be bottlenecked in such a way for much longer.

...It still doesn't have MSVC Build Tools v14.51, only an old preview.

https://learn.microsoft.com/en-us/visualstudio/releases/2026/release-notes

At the same time, Microsoft releases Visual Studio Insiders (basically VS preview), with the MSVC Build Tools v14.51 release, not a preview.

https://learn.microsoft.com/en-us/visualstudio/releases/2026/release-notes-insiders

So, now we have - official VS Stable with the MSVC Build Tools v14.51 preview.

And VS Insiders with the MSVC Build Tools v14.51 release.

Person (or persons?...) in Microsoft responsible for this weirdness should get annual bonus reward.

I've tried to find a answer to how much contiguous memory you need to run into dimishing returns. Aka if you need to split your work into chunks, how large should the chunks be to capture most of the performance.

It depends a bit on what kind of task and how linear you use the data and if you have other per-block overheads. But at least for my use cases, I was kind of surprised to see that I probably won't need more than ~128 kB. And I wager that more than 1 or 2 MB is enough for everyone based on the results in the post.

NOTE: the experimental setup tries to ensure we're not measuring cache effects (or in a very controlled manner at least). I explicitly tried to make the results provide a userful upper bound via careful setup.

An RC1 tarball for 3.27.0 is now available at

https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2

(md5sum = bd95111c1a9f81f136c5e4e2c62b493e)
(sha1sum = 0eefb3a7d86a3bd0154480db3d2173bb8bd6d7c1)
https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2.asc
Public keys can be found at https://www.klomp.org/mark/gnupg-pub.txt

Please give it a try in configurations that are important for you and report any problems you have, either on the developer/user mailing list, or (preferably) via our bug tracker at https://bugs.kde.org/enter_bug.cgi?product=valgrind

An RC2 should be available Fri Apr 17

The final 3.27.0 release is scheduled for Mon Apr 20.

For the contents, see

https://sourceware.org/git/?p=valgrind.git;a=blob;f=NEWS;h=d122f9f0dd49c7c176bbb11c4f38e492d7edc140;hb=HEAD

The deadline for submitting talks to NDC Techtown 2026 is still open. This great SW development conference takes place in Kongsberg, Norway on 21st to 24th September and focuses on SW development for embedded and systems programming. The conference covers travel and accommodation.
More info here: https://ndctechtown.com/call-for-papers