Dreadfully sorry but I don't understand this - I'm not a Windows user. Don't you have to buy Windows 11? It's not ad supported (like US broadcast TV) is it?
Wow, as a non-Windows person, I'm kind of shocked that Windows users put up with ads and "promoted" content. If you pay for Windows, it should be yours to do with as you wish.
This is from 2019, prior to the finalization of modules in the standard. I'd be interested in how many of these issues were unaddressed in the final version shipped.
There isn't much of a final version shipped. It's pretty well understood that modules are underspecified and their implementation across MSVC, clang, and GCC is mostly just ad-hoc based on an informal understanding among the people involved in their implementation. Even ignoring the usual complexity and ambiguity of the C++ standard, modules are on a whole different level in terms of lacking a suitable formal specification that could be used to come close to independently implementing the feature.
And this is ignoring the fact that none of GCC, clang, or MSVC have a remotely good implementation of modules that would be worth using for anything outside of a hobby project.
I agree with the other commenter who said modules are a failure of a feature, the only question left is whether the standards committee will learn from this mistake and refrain from ever standardizing a feature without a solid proof of concept and tangible use cases.
I did prior to 2017. I realized the committee was 75% politics and people with a lot of time and devotion pushing their pet projects, and about 25% about addressing actual issues faced by professional engineers and decided it was no longer worth the time and effort and money.
The committee is full of very smart and talented people, no dispute about that, but it's also very silo'd where people just work on one particular niche or another based on their personal interests, and then they trade support with each other. In discussions it's almost never the case that features are added with any consideration towards the broader C++ audience.
You learned nothing because the extent of your knowledge tends to be rather superficial when it comes to C++.
Office does not use C++ modules, what Office did was make use of a non-standard MSVC feature [1] which reinterprets #include preprocessor directives as header units. Absolutely no changes to source code is needed to make use of this compiler feature.
This is not the same as using C++20 modules which would require an absolutely astronomical amount of effort to do.
In the future, read more than just the headline of a blog post if you wish to actually understand a topic well enough to converse in it.
Are you sure?
I've been confidently wrong about stuff before. Embarrassing, but it happens..
And I've been working with many people who are sometimes wrong about stuff too.
With LLMs you call that "hallucinating" and with people we just call it "lapse in memory", "error in judgment", or "being distracted", or plain "a mistake".
Yeah, for the most part. But I've even had a few instance in which someone was very sure about something and still wrong. Usually not about APIs but rather about stuff that is more work to verify or not quite as timeless.
Cache optimization issue or suitability of certain algorithms for some problems even.
The world is changing a lot and sometimes people don't notice and stick to stuff that was state-of-the-art a decade ago.
But I think the point of the article is that you should have measure in place which make hallucinations not matter because it will be noticed in CI and tests.
For the most part, yes. Because people usually read docs and test it on their own.
But I remember a few people long ago telling me confidently how to do this or that in e.g. "git" only to find out during testing that it didn't quite work like that.
Or telling me about how some subsystem could be tested. When it didn't work like that at all.
Because they operated from memory instead of checking. Or confused one tool/system for another.
LLMs can and should verify their assumptions too. The blog article is about that. That should keep most hallucinations and mistakes people make from doing any real harm.
If you let an LLM do that it won't be much of a problem either.
I usually link an LLM to an online source for an API I want to use or tell it just look it up so it is less likely to make such mistakes. It helps.
I do agree. I still think that the article articulates a very interesting thought... the better the input for a problem, the better the output. This applies both to LLMs but also for colleagues.
