Some programming blog
Modules have been the subject of many controversies in the C++ community in the recent past and there seem to be some misconception floating around recently about modules. Important decisions will soon be made, and I wanted to clear some of the facts and raise potentially good questions about modules and the path to their adoption.
The debate on whether we should support macro in modules has always been very polarized. This is a response to the recent Reddit post Really think that the macro story in Modules is doing more harm than good and the paper p1052r0. I want to make a quick post showing what is possible to do, and how we can solve the need for modular macros and find common ground in this story.
In this post, we’re gonna explore what reflection facilities are available to us today and what is possible to achieve given its limitations.
Ah, good old Oriented Object Programming. Have a problem? Just make an interface, and implement it! Simple as that heh? Well no. Polymorphism as done today with classic OOP is intrusive, forces polymorphic behavior even in place where it’s not really needed, almost always imply heap allocation, needs to carry the vtable pointer and the list goes on. Fortunatly, other pattern and idiom exists. Here’s an approach that might change how you see polymophism, and the problem it tries to solve. Let me introduce the Concept-Model idiom, also called runtime concept, or virtual concept.
I’m not the inventor of this idiom. I’m sure everyone doing OOP ended up doing something that look like it in some way (hint: Adapter pattern). The first time I saw the idea in a concrete way was in the Sean Parent’s talk Inheritance Is The Base Class of Evil. Thanks to him, I manage to use it and practice it a lot. I want to share what I’ve learned by playing around with this pattern.
C++ templates is often blamed of horrible errors. Diagnostics can be painfully large for users of heavily templated libraries. And indeed, there can be pretty horrible errors only by using the STL.
Library writers often are confronted with a choice: being sfinae friendly, or output a nicely crafted compiler error with
While experimenting ways to output errors in the cleanest way possible, I have found a trick to both enable sfinae while providing custom error messages that may depend on multiple conditions.