Home » Blog » Categories »

Providing a stable memory address to an external API

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...

 

 

C++23: More Small Changes -- Sandor Dargo

By Blog Staff | Mar 18, 2024 01:54 PM | Tags: None

SANDOR_DARGO_ROUND.JPGIn 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 for std::stack and std::queue. They don’t provide such overloads. If you want to initialize them with a pair of iterators, you need an intermediary std::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 stack or queue on 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 ...

Safety, Revisited -- Lucian Radu Teodorescu

By Blog Staff | Mar 15, 2024 01:51 PM | Tags: None

logo.pngLast 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 ...

 

Starting a C++ project with CMake in 2024

By Meeting C++ | Mar 15, 2024 11:22 AM | Tags: meetingcpp cmake basics

A post on how I've recently started a new C++ project.

Starting a C++ project with CMake in 2024

by Jens Weller

From the article:

Last year I've written last year about my plans to return to C++, taking on some project ideas with C++20 and CMake.

The first project is now in its beginning, so I thought to share the steps so far. Some of this blog post is covered by my recent talk Starting a modern C++ project with CMake in 2024. In this post I'm going stay within the parts of the build tooling, following up with the code in other posts.

After working through the official CMake tutorial...

 

C++23: Allocator Related Changes -- Sandor Dargo

By Blog Staff | Mar 13, 2024 01:48 PM | Tags: None

SANDOR_DARGO_ROUND.JPGIn this post, we are going to review two changes related to allocators in C++. One is about providing size information about the allocated memory and the other is about how CTAD should happen for containers with non-default allocators.

C++23: Allocator Related Changes

by Sandor Dargo

From the article:

P0401R6 gives a new way to allocate memory on the heap to limit spurious reallocations.

The new interface of std::allocator looks like this, but there is also a free function version of it.

template<class Pointer>
  struct allocation_result {
    Pointer ptr;
    size_t count;
  };

// this class already exist:
namespace std {
  template<class T> class allocator {
   public:
   // lots of existing things
   // ...
   // this is the old way to allocate 
   [[nodiscard]] constexpr T* allocate(size_t n);

   // and this is the new way
   [[nodiscard]] constexpr allocation_result<T*> allocate_at_least(size_t n);

   // the interface for deallocation does not change
   constexpr void deallocate(T* p, size_t n);
  };
}
As you can see, allocate_at_least takes a number and it should allocate enough memory for at least that many instances of T on the heap. While allocate returns a single pointer to the beginning of the allocated memory, allocate_at_least returns a new struct called allocation_result which has two members, the “usual” pointer to the beginning of the allocated memory (ptr) and the number of Ts memory got allocated for (count). count must be at least as large as the input parameter n, but it can also be more.

C++20 Concepts Applied – Safe Bitmasks Using Scoped Enums -- Andreas Fertig

By Blog Staff | Mar 11, 2024 01:14 PM | Tags: None

logo.pngIt can be hard to follow code using enable_if. Andreas Fertig gives a practical example where C++20’s concepts can be used instead.

C++20 Concepts Applied – Safe Bitmasks Using Scoped Enums

by Andreas Fertig

From the article:

The idea is that the bit-operators are often used with enums to create bitmasks. Filesystem permissions are one example. Essentially you want to be able to write type-safe code like this:

using Filesystem::Permission;
Permission readAndWrite{
  Permission::Read | Permission::Write};

The enum Permission is a class enum, making the code type-safe. Now, all of you who once have dealt with class enums know that they come without support for operators. Which also is their strength. You can define the desired operator or operators for each enum. The issue here is that most of the code is the same. Cast the enum to the underlying type, apply the binary operation, and cast the result back to the enum type. Nothing terribly hard, but it is so annoying to repeatedly type it.

Anthony solved this by providing an operator, a function template that only gets enabled if you opt-in for a desired enum. Listing 1 is the implementation, including the definition of Permission.

Aggregates: C++17 vs. C++20 -- Andreas Fertig

By Blog Staff | Mar 9, 2024 01:13 PM | Tags: None

me.pngSometimes the small changes between two C++ standards really bite you. Today's post is about when I got bitten by a change to aggregates in C++20.

Aggregates: C++17 vs. C++20

by Andreas Fertig

From the article:

A harmless example

Attendees of my training classes usually assume that I know everything. I can say sorry, but that's not the case. One day in the past, I showed the following example during a class:

struct Point {
  int x;
  int y;
};

Point pt{2, 3};

The class did cover C++17 and C++20. The code of Point is a reduced version for this post. We were talking about C++17's structured bindings. I use Point to show the decomposition using C++ Insights.

I showed the behavior and certain variations while answering questions from the attendees. One question was about move and copy. The question leads me changing the initial code to the following one:

struct Point {
  int x;
  int y;

  Point(Point&&) = delete;  A
};

Point pt{2, 3};

As you can see, in A, I deleted the move constructor. As far as I remember, this topic was more or less the last one for this day. Everything went well and as expected.

Works on my machine

The next morning one of the attendees approached me with the question of why the code didn't compile on his machine. My usual answer here is that if C++ were be easy, I wouldn't have the job I have. Somehow this never shuts down such questions. I like curious attendees.

He shared his code via Compiler Explorer. Guess what? His code looked exactly like mine but didn't compile. Here is the error message from the compiler...