Home » Blog » Categories » Articles & Books

Articles & Books

DR20 - The Equality Operator You Are Looking For -- Sandor Dargo

By Blog Staff | Feb 13, 2024 05:34 PM | Tags: None

SANDOR_DARGO_ROUND.JPGWe delve into how C++20 introduced changes to object comparisons, leading to unexpected behavior and the need for matching operator!= declarations.

DR20 - The Equality Operator You Are Looking For

by Sandor Dargo

From the article:

When I see DR, I immediately think about Disaster Recovery. That’s due to my first corporate job where I worked as a Database Administrator and we had regular exercises to simulate events when datacenters would be unavailable.

When you see DR in the title of a C++ proposal, it’s not about a disaster, it’s more about a bug. DR stands for defect report. But the paper itself is usually not about reporting that there is a problem - that has been already done -, but more about proposing a solution.

What’s more important is that defect reports are not becoming part of the latest standard, they retrospectively change the one that introduced the defect.

A defect of C++20’s equality operator

P2468R2 is addressing a problem that was introduced by C++20. C++20 brought us the spaceship operator (operator<=>), but it further changed the logic of object comparisons. It changed the meaning of == and != and how overload resolution applies to them.

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

By Blog Staff | Feb 9, 2024 01:05 PM | Tags: None

Sometimes 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:

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:


	

		
			

				
					

						
2
3
4
5
6
7
8

					

						
				
					

						
struct Point {
  int x;
  int y;

  Point(Point&&) = delete;  A 

};

Point pt{2, 3};

					

						
			

		
	




	

		
			

				
					

						
2
3
4
5
6
7
8

					

						
				
					

						
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.



	

		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:



      

      
      
      
    

      
      
      
      
    

      

        
What are senders good for, anyway? -- Eric Niebler

        
By Eric Niebler | 
        Feb 6, 2024 12:46 PM 
         | 
        Tags: 
                    c++26

        

	In a recent blog post, Eric Niebler gets inside the soon-to-be-standard async programming model and shows why you should care.



	



	

		What are senders good for, anyway?





	

		

			by Eric Niebler

	





	From the article:



	

		At the heart of P2300 is a simple, elegant (IMHO) core that brings many benefits, but it’s hard to see that forest for all the trees.

	

		So let’s make this concrete. In this post, I’ll show how to bring a crusty old C-style async API into the world of senders, and why you might want to do that.



      

      
      
      
    

      

        
How I Learned to Stop Worrying and Love Juggling C++ Atomics -- brilliantsugar

        
By Felix Petriconi | 
        Feb 4, 2024 07:07 AM 
         | 
        Tags: None  

        

	In his recent blog post brilliantsugar talks about technics to find race conditions in multithreading code by using different tools.



	

		How I Learned to Stop Worrying and Love Juggling C++ Atomics

	

		by brilliantsugar





	From the blog post



	

		As most C++ programmers are aware, courtesy of Herb Sutter, programming lock-free data structures is akin to juggling razor blades. Reasoning about concurrent programs is already complex enough but modern CPU memory models are so complicated that they manage to make it even harder. The prevailing suggestion you often come across is to steer clear of lock-free programming entirely.

	

		In this article, I share the adventures of exploring methods for formally verifying lock-free C++ code. To showcase three different approaches, I delve into the implementation of a lock-free triple buffer data structure.





	 



	 

      

      
      
      
    

      

        
Class Invariants --  Andrzej Krzemieński

        
By Andrzej Krzemienski | 
        Feb 4, 2024 06:05 AM 
         | 
        Tags: None  

        

	Andrzej talks in his recent blog post about class invariants.



	

		Class Invariants





	

		by Andrzej Krzemieński





	About the blog post:



	

		The primary motivation for defining a class in C++ is to reflect and maintain a class invariant. In this post we will see what class invariants are and how you deal with them. Class invariants are important part of C++, even though there is no “invariant” keyword in C++.



      

      
      
      
    

      
      
      
      
    

      

        
C++20 Concepts Applied -- Andreas Fertig

        
By Blog Staff | 
        Jan 30, 2024 01:29 PM 
         | 
        Tags: None  

        

	me.pngIn this post, we'll dive into implementing this technique in C++17 and then explore how it evolves with the application of C++20 concepts to the code. The goal is to simplify the code by eliminating the need for cumbersome constructs like enable_if and introduce further improvements in C++23.



	

		C++20 Concepts Applied - Safe Bitmasks using Scoped Enums

	

		by Andreas Fertig





	From the article:



	

		In 2020 I wrote an article for the German magazine iX called Scoped enums in C++. In that article, I shared an approach of using class enums as bitfields without the hassel of having to define the operators for each enum. The approach was inspired by Anthony William's post Using Enum Classes as Bitfields.

	

		Today's post aims to bring you up to speed with the implementation in C++17 and then see how it transforms when you apply C++20 concepts to the code.

	

		One operator for all binary operations of a kind

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



      

      
      
      
    

      

        
The decorator pattern: From basic to advanced concepts in C++ -- John Farrier

        
By John Farrier | 
        Jan 25, 2024 10:55 AM 
         | 
        Tags: None  

        

	The Decorator Pattern stands out for its unique ability to dynamically add new functionalities to objects without altering their structure.



	

		The decorator pattern: From basic to advanced concepts in C++

	

		John Farrier





	From the article:



	

		The Decorator Pattern allows developers to seamlessly decorate or wrap objects with new behaviors or responsibilities, ensuring that the enhancements are scalable, manageable, and, most importantly, interchangeable. This capability is crucial in an era where software requirements are constantly evolving, demanding adaptable and resilient systems to change.

	

		Let’s illustrate this with a basic C++ example. Consider a window in a user interface as the Component. You want to add functionalities like scrollbars or a border without redesigning the window itself.

	

		Here’s a simplified version of how you might implement this:

	
class Window { // Component
public:
    virtual void draw() = 0;
    virtual ~Window() {}
};

class SimpleWindow : public Window { // Concrete Component
public:
    void draw() override {
        // Draw the window
    }
};

class WindowDecorator : public Window { // Decorator
protected:
    Window* window;
public:
    WindowDecorator(Window* wnd) : window(wnd) {}
    void draw() override {
        window->draw(); // Delegate to the component
    }
};

class ScrollbarWindow : public WindowDecorator { // Concrete Decorator
public:
    ScrollbarWindow(Window* wnd) : WindowDecorator(wnd) {}
    void draw() override {
        WindowDecorator::draw(); // Draw the window
        drawScrollbar(); // Add scrollbar
    }
private:
    void drawScrollbar() {
        // Draw the scrollbar
    }
};

	

		

		In this example, SimpleWindow is a Concrete Component that can be decorated with additional features. WindowDecorator is a Decorator that holds a reference to a Window object and delegates the draw operation to it. ScrollbarWindow is a Concrete Decorator that adds a scrollbar to the window.