I think the conclusion section should indicate that they are based entirely on GCC 16's behavior and current implementation. We should avoid generalizing one compiler's behavior and performance. Curious how this same test would behave once clang ships C++26 reflection.
I explicitly mentioned that GCC 16.1 was the compiler used in the benchmarking section, do you think I also need to add a disclaimer in the conclusion section as well?
Regardless, I don't think things are going to differ much with Clang. Without PCH/modules, standard header inclusion is still the "slow part" of C++ compilation, regardless of the compiler used and the standard library used (libstdc++ vs libc++). `#include` is fundamentally the same on any modern compiler.
Because the reflection feature itself seems quite fast on GCC (compared to the cost of the header), I predict the results will be similar on Clang as well.
That is true, but on the other hand Modules were standardized more than 6 years ago.
Promises and claims have been made for longer than that on how Modules would have improved compilation times and made everyone's lives easier. In 2026, I still have to see any real evidence of that, especially when PCH + unity builds are much easier to use (except on damn Bazel, which supports neither) and deliver great results.
If after 6+ years of development Modules are still so far behind, it is fair to question if the problem is with the design/implementability of the feature itself.
> it is fair to question if the problem is with the design/implementability of the feature itself.
The module story is just insane. How was it possible to get such a big feature into the standard without any working reference implementation? Isn't this the requirement for standard proposals to get accepted? If I compare this with how they treated JeanHeyd and his #embed proposal, the difference is staggering. To me it seems like a few powerful comittee members wanted to get modules into C++20 at any cost. This was just irresponsible.
There was in visual studio which has had it other than minor details.the real problem is tools are needed to make modules work and those needed a lot of work. The work was already partially there because it's the same work that Fortran needs which tools supported but there were just enough details different to be annoying. Fortran modules were something that were always an afterthought and when tools started realizing that this is going to be a big deal, they decided they had to do it right, which took a lot of time too.
Maybe you forget Hacker News of 10 years ago, but in 2015-2016, everyone was complaining C++ doesn't have modules and how awful it must be because they're not modules. Now that C++ has modules, they're complaining about how it has modules.
People are not complaining about the fact that C++ has modules, but about their usability and effectiveness. The compile time benefits seem modest and I have seen reports that it breaks Intellisense. (Maybe that's not true anymore?)
As Vittorio said, if it takes compiler vendors so long to implement them properly, maybe the design wasn't that good after all?
My point was: if you add such a big feature, shouldn't the standard require a sufficiently complete implementation? Otherwise, how can they assess whether the proposal actually works in practice and lives up to its promises?
Agree that proof of implementation and real world experience should be a requirement for standardization. But it is a catch-22: implement it's are probably not always too keen to spend time on a large feature if it is not clear that it will be standardized.
In practice both clang and VS have had some form of module support for quite a while, but the final standard ended up being different from either implementation (shaped by their experience, and certainly with inevitable last minute inventions).
I wonder if for some features the committee should vote for general guidelines, the delegate a third party (one or more implementors) to come up with both an implementation and standardese with the understanding that it will be fast-tracked in wit too much bike-shedding
Again, they had a sufficiently complete implementation. That implementation was in Visual Studio, clang had a very different implementation. The standard decided to take the Microsoft version. There are pros and cons to both and I will not fault the decision but either way one of the two had to lose and there is no surprise that for something complex it will take a long time to reimplement it to whatever the new standard is.
If the implementation really was sufficiently complete, then this is even worse! Why did they choose to vote something into the standard that is very complex and difficult to implement, but does not live up to the promises? Maybe they thought it would improve in the future, but isn't this a huge gamble?
I have heard rumors that certain people in the Visual Studio team have exaggerated the state of their modules implementation to speedrun the standardization process. I have no idea if that is really true, but it would explain a lot of things...
I'm not the only one who is asking these questions:
> I don’t know if they exaggerated their claims at the time, or if they didn’t properly fund the Visual Studio team since or what, but you can’t tell me 8 years wasn’t enough to make syntax highlighting work with modules. And if it is, then maybe there was something deeply wrong in their proposal and the committee should have asked to see the receipts before voting yes.
It should be possible to have the PPU emulation capture all of the final register state per pixel (or scanline if accuracy isn't paramount) and have the GPU render each pixel using only that state, doing the layer blending, color math, and mode 7 calculations as necessary. Based on MVG's video breaking down the draw commands performed it doesn't look like that's how Super ZSNES have implemented their PPU - it seems to render tile by tile for BGs (and OBJ?) and line by line for mode 7. That'll be a bit inaccurate but it's likely necessary to implement some of their visual enhancement tricks.
I came up with something similar to your idea, a GPU compute PPU for future Snes9x. What they're doing is using legacy fixed-function API to draw quads, then blend a bump map on with the final image. It's weird. We have the tools to do some really cool things with GPUs, but they chose this. I'm more impressed by all the post-processing shaders people have come up with for all the other emulators.
Very cool! Checking out the Van Gogh painting in the viewer I can just barely see the depth of the brush strokes. Shame you can't look 90 degrees off axis to see the protrusion effect with the bulky outer frame in the way.
Very cool idea, but unfortunately the browser doesn't allow users to select which channel of their audio interface to use as input. So unless you're plugging your guitar into input 1 this doesn't work out. I have my microphone in input 1 and my guitar in input 2.
Great instructional video. First place I learned E natural minor with his scale fragments section.
Yes, not a new technique by any stretch of the means. AFAIK John Petrucci takes a less aggressive approach with raising BPM. Funnily, Shawn Lane goes into a very similar methodology >30 years ago[1].
Are we assuming that "testing" is limited to only exercising the single-threaded behavior of a function? I'm curious how others approach effective testing of multi-threaded behavior.
Sanitization of data is such a strange security practice to me. It feels like any sort of vulnerability sensitive to data sanitization just boils down to a failure to properly encode or escape data into a target language that is susceptible to injection attacks e.g. SQL, HTML, javascript. Is there a real-world scenario where data sanitization is required where proper data encoding/escaping is not the better solution?
There are tons of languages and frameworks made by developers who know what they are doing that do not treat everything blindly like strings.
For SQL in particular, you should never build queries directly from user input - any modern database supports bind variables or parameters, which completely eliminate any need for sanitizing input.
I agree with you regarding sanitization, and I'd add further that having to sanitize input for security purposes is a big sign of code smell and an overall insecure code by design.
I feel like answering this comment could start a possible argument, which I have no interest in doing.
I do, however, want to point that anyone interested in comparing language design choices can conclude by themselves this is likely a strong factor.
You can find references like the classic "PHP: a fractal of bad design"[1] which not only talks about the language itself but SQL injection, error handling and tons of other issues. It summarizes most of the important points.
I can also add a few issues like[2][3], which unfortunately are not isolated incidents: these are a reflection of core design decisions and how the language approaches software design as a whole.
I stand by my point, which I'll define more precisely as:
"A badly-designed language either makes it hard for developers to do good choices, or makes it easy for developers to do bad choices."
PHP is not alone, but it is a prime example of this.
You can disagree with this assessment - and that's OK.
I have to disagree, because your assessment is outdated and somewhat shallow. My impression is that it doesn't rest on much real programming experience with PHP either.
To stay with the topic, these arguments are in essence a way of trying to hold PHP as a language accountable for functions it exposed in its since long (about a decade ago) deprecated original mysql extension. These functions actually belong to the underlying C library developed by MySQL, and as has been the custom with tons of functionality brought into PHP from elsewhere over the years, the entire library was relayed. The very same functions - e.g. escape_string(), the culprit "luring" users away from parameterization - are still available in Oracle's mysql C library, and are to some extent also available in, for example, the mysql Python connector through its C extension API.
At the time "a fractal of bad design" was published a handful of its talking points were already no longer actual. It got tired and trope-y years ago, and PHP isn't what it was 15 years ago. Referencing the article today is about as valid as regurgitating "classic" 1950s health advice to Ironman triathletes or something.
As I said, I have no intention of starting an argument.
I would just like to point out a few issues:
A) I deliberately focused on the language itself in my claims.
The functions I cited earlier were meant to illustrate the side effects of a certain mindset of the core language.
Keep in mind: these functions are not from some random library in the ecosystem, but from the core library of the language, providing core functionality. And that hasn't changed, nor the functions.
B) You've made a number of statements in response to my comments, but I don't see any supporting references.
The only justification you've given is your own opinion that "the article is too old and not relevant anymore".
Which takes us to point C.
C) I skimmed through the article again, along with the general documentation of the language, and I stand by this statement:
"Every major point in that article about the language is as relevant today as it was in 2012."
PHP might work fine for templating some web pages, but so does Jinja. As a general programming language, it falls short in too many ways to list here. You can revisit the original article I mentioned before for a more comprehensive list, in particular the "core language" section.
Well, at least that's my opinion. As I said, you're free to disagree - and that's OK.
--
Side note: The easiest approach during a disagreement in an online discussion is to write a lot of "opinion-based statements" as if they were facts, and leave everything else as an exercise for the reader.
If you want to be taken seriously, please don't do that.
And tons of such frameworks have been written in PHP; prepared statements with an adapter-agnostic database connection layer are first-class citizens in PHP.
>"Is there a real-world scenario where data sanitization is required where proper data encoding/escaping is not the better solution?"
In context of SQL queries which accept variable input, the only correct approach is to parameterize the queries, never to string-encode the variables. So, yes. But perhaps you implied parameterization as well.
