October 25, Pavia, Italy
November 6-8, Berlin, Germany
November 3-8, Kona, HI, USA
By Marco Arena | Apr 4, 2024 03:35 AM | Tags: sobjectizer intermediate c++20
A new episode of the series about SObjectizer and message passing:
SObjectizer Tales – 26. Dispatcher selection
by Marco Arena
From the article:
In this episode we explore guidelines and considerations for binding agents to dispatchers. We'll emphasize the significance of asking pertinent questions rather than expecting definitive answers, as the decision-making process hinges on the unique requirements of the system.
By Blog Staff | Apr 3, 2024 09:31 AM | Tags: None
The annual global C++ developer survey is now open. As the name suggests, it's a one-pager:
2024 Annual C++ Developer Survey "Lite"
Please take 10 minutes or so to participate! A summary of the results, including aggregated highlights of common answers in the write-in responses, will be posted publicly here on isocpp.org and shared with the C++ standardization committee participants to help inform C++ evolution.
The survey closes in one week.
Thank you for participating and helping to inform our committee and community!
By TartanLlama | Apr 3, 2024 08:14 AM | Tags: community
The session list for Pure Virtual C++ 2024 is live:
Pure Virtual C++ 2024 Sessions Announced
By Sy Brand
From the article:
- Automated Testing of Shader Code with Keith Stockdale
- Message Handling with Boolean Implication with Ben Deane
- I Embedded a Programming Language In Debug Information with Sy Brand
- Enhancing C++ development with Copilot Chat with Sinem Akinci
- Progress Report: Adopting Header Units in Microsoft Word with Zachary Henkel
By Marco Arena | Mar 28, 2024 02:23 AM | Tags: sobjectizer intermediate c++20
A new episode of the series about SObjectizer and message passing:
SObjectizer Tales – 25. Runtime telemetry
by Marco Arena
From the article:
In this episode we learn how to get insights into application performance using SObjectizer's monitoring system.
By Blog Staff | Mar 26, 2024 10:47 AM | Tags: None
I delivered a keynote, C++ and the Next 30 Years, at the 2024 CPP-Summit conference in Beijing, China. Experiencing the culture, the people, and the landscape was tremendous. In this post I’ll cover some of the points in my future-looking C++ talk and share my experience giving a talk for the first time in China.
C++ and The Next 30 Years
by David Sankel
From the article:
My talk: C++ and the Next 30 Years
The title of my keynote was C++ and the Next 30 Years which covered C++’s evolution, the changing landscape of programming languages, and the influence of AI. Here I break down some of my talk’s key points.The next 10 years
In the next 10 years I expect C++ modules to become more accessible. Most C++ vendors have at least some support and CMake recently announced its feature set. However, transitioning existing code bases and, in many instances, bespoke build systems will be a great obstacle.Package manager usage is on the rise, but the growth curve is slow. I don’t expect any tool to capture more than 40% market share by the decade’s end.
By Blog Staff | Mar 21, 2024 10:42 AM | Tags: None
In C++, shadowing occurs when a name in one scope hides an identical name in another scope, sparking debate over its merit. This article explores scenarios where shadowing can either protect code integrity or hinder its evolution, highlighting its dual nature and impact on code maintenance. Join Raymond as he unravels the complexities of shadowing in C++, revealing its intricate balance between benefit and drawback.
Is shadowing a member variable from a base class a bad thing? Maybe, but maybe not.
by Raymond Chen
From the article:
What is shadowing? In C++, shadowing is the name given to the phenomenon when a name in one scope hides an identical name in another scope.
Is shadowing bad? That’s a harder question.
Whether shadowing is good or bad depends on the order in which the conflicting names were introduced.
Suppose you have a class library, and one of the classes is this:
struct Tool { int a; };And suppose some customer uses your class like this:
class Wrench : public Tool { private: int a; };In this case, shadowing is probably unintended. The customer has accidentally shadowed
Tool::a, and any references toain theWrenchclass will refer toWrench::a, even if the author meant to accessTool::a.Meanwhile, you have another customer who writes this...
By Marco Arena | Mar 21, 2024 01:00 AM | Tags: sobjectizer intermediate c++20
A new episode of the series about SObjectizer and message passing:
SObjectizer Tales – 24. Delivering messages at shutdown
by Marco Arena
From the article:
In this episode we learn a feature of SObjectizer to perform arbitrary actions just before shutdown, including message delivery.
By Meeting C++ | Mar 20, 2024 02:07 AM | Tags: performance meetingcpp intermediate experimental community c++20 advanced
A post on how to provide a pointer to a Qt Model/View or other APIs storing pointers to their data without using shared_ptr or unique_ptr for the actual object.
Providing a stable memory address
by Jens Weller
From the article:
Some APIs allow you to store a pointer to your data element. This is used to access additional information from your types to display them in Model/View Architecture.
A while ago I showed how you can implement a tree with shared_ptr and enable_shared_from_this and then display this in QTreeView. And when working on my current project I knew this problem would come around again. Maybe not for a tree and a tree view, but I'll clearly need to have some way to have ui panels display and edit my data classes and store a stable memory adress as a pointer in Qt models. Back in 2015 the Qt5 example still used a pointer allocated with raw new for this, in Qt6 the example uses unique_ptr. Using shared_ptr for this back in 2015 was a good decision, and the code works very well. For the moment I don't see that my current project would need to make use of enable_shared_from_this, so using unique_ptr would be a good option...
By Blog Staff | Mar 18, 2024 01:54 PM | Tags: None
In this post, we continue discovering the changes introduced by C++23. We are going to look into three (and a half) small changes, each affecting constructors of some standard library types. We’re going to see how new constructors for container types, a new range constructor for string_view and some default template arguments for pair.
C++23: More Small Changes
by Sandor Dargo
From the article:
As of C++20, almost all container-like objects (containers and container-adaptors) can be initialized with a pair of iterators.
std::vector<int> v{42, 51, 66}; std::list<int> l(v.begin(), v.end());All of them, except forstd::stackandstd::queue. They don’t provide such overloads. If you want to initialize them with a pair of iterators, you need an intermediarystd::initiailizer_list.
std::vector<int> v{42, 51, 66}; // std::queue<int> q1(v.begin(), v.end()); // DOESN'T COMPILE! std::queue<int> q2({v.begin(), v.end()});This inconsistency, at first, looks like a small inconvenience. But its effects are much deeper. While using the
stackorqueueon its own is not a big burden, if you want to offer functionality that works with all container-like objects, you have a higher price to pay.Due to the lack of an iterator-pair-based constructor, you either have to ...
By Blog Staff | Mar 15, 2024 01:51 PM | Tags: None
Last year saw a proliferation of talks and articles about safety in C++. Lucian Radu Teodorescu gives an overview of these and presents a unified perspective on safety.
Safety, Revisited
by Lucian Radu Teodorescu
From the article:
In his presentation at C++ now [Parent23a], Sean Parent presents the reasons why it’s important to discuss safety in the C++ world, tries to define safety, argues that the C++ model needs to improve to achieve safety, and looks at a possible future of software development. This same talk was later delivered as a keynote at C++ on Sea [Parent23b].
Sean argues the importance of safety by surveying a few recent US and EU reports which have begun to recognise safety as a major concern [NSA22, CR23, WH23a, EC22]. There are a few takeaways from these reports. Firstly, they identify memory safety as a paramount issue. The NSA report [NSA22], for instance, cites a Microsoft study noting that “70 percent of their vulnerabilities were due to memory safety issues”. Secondly, they highlight the inherent safety risks in C and C++ languages, advocating for the adoption of memory-safe languages. Lastly, these documents suggest a paradigm shift in liability towards software vendors. Under this framework, vendors may face accountability for damages resulting from safety lapses in their software.
Building on the reports that underscore the significance of safety, Sean delves into deciphering the meaning of ‘safety’ in the context of software development. After evaluating several inadequate definitions, he adopts a framework conceptualised by Leslie Lamport [Lamport77]. The idea is to express ...
