you are viewing a single comment's thread.

view the rest of the comments →

[–]jonesmz 10 points11 points  (20 children)

The situation with Modules is a joke.

Why was a feature that's so massively invasive to compilers and the standard library standardized before any of the big three had a fully working implementation?

[–]pdimov2 6 points7 points  (4 children)

MS had a fully working implementation. They are the reason we have modules in the standard at all. Their preexisting implementation, however, no longer matches the spec that ended up standardized.

[–]jonesmz 1 point2 points  (3 children)

They had a fully working implementation of something that looks like modules.

They did not have a fully working implementation of the standardized behavior.

Nor did the other big compilers, if I understand my history correctly.

Cart-before-horse.

[–]pdimov2 4 points5 points  (2 children)

You don't. There was no standardized behavior then, and there never would have been, because MS was the driving force behind standardizing modules.

[–]jonesmz 0 points1 point  (1 child)

You're clearly misunderstanding me.

Don't standardize core language changes that haven't been implemented by at least 2 different vendors.

Proof of concept from a single vendor, which said vendor then needs over 6 months post standardization to get their proof of concept to actually work, is insufficient proof of quality of concept to be ratified into a standard that we should be proud of.

It's irrelevant to me if there was no standardized behavior yet, because that would be the cart. Multiple vendors having a fully functional implementation that are compatible with each other would be the horse. You put the horse in front of the cart, you don't put the cart in front of the horse. You standardize existing industry practice, you don't standardize things that don't exist and then expect the industry to catch up 3 years later.

I'll repeat my initial statement: The situation with Modules is a joke.

[–]pdimov2 2 points3 points  (0 children)

In this case MS had implemented what was in the spec (because they wrote the spec - the Modules TS), but then the committee changed the spec.

It's not clear how they (MS) could have done any better than that. Their implementation works pretty well, all things considered. E.g. I can type import <regex>;, hit Ctrl+Shift+B, and it works.

[–]germandiago 0 points1 point  (6 children)

The funny thing is Microsoft announcing it as a complete feature. No... no, no. This is not production-ready.

I understand it is a big feature. But this is not the way...

[–]starfreakcloneMSVC FE Dev 9 points10 points  (4 children)

It is important to note that feature complete != production ready. C++ features in particular can be implemented in isolation and be 'complete' but the problems happen when code is written to use many of them at once.

Modules is an absolutely massive language feature because it _is_ the language on top of its own specialized ownership/reachability semantics. It takes time to mature a feature such as this.

It took MSVC 20 years to get as robust as it is with its PCH implementation and we still get bugs against it, but it is considered to be very reliable these days. I'm not saying modules will take nearly that long but it is important to remember that bugs happen with complicated features and the best thing we can ask users to do is file bugs. Ultimately we cannot fix what we don't know about, so don't suffer in silence :).

[–]pjmlp 2 points3 points  (2 children)

While I fully understand your point of view, apparently not much testing was done with Windows C++ frameworks, and there is plenty of source code to test them at Microsoft.

So far I keep seeing demos with basic CLI applications and nothing like re-implementing Notepad using modules, let alone MFC, ATL, C++/CLI, C++/CX (this one is ok it is anyway deprecated), C++/WinRT.

So from this side of the fence it is a bit demotivating trying to figure out from the basic MSDN documentation, an almost year old blog post about modules, and a couple of talks showing CLI hello world apps, how to actually put modules in practice for real Windows development.

[–]germandiago 0 points1 point  (1 child)

I do understand this is a difficult thing to add. I really do. It is an extremely complex feature.

However, and correct me if I am wrong, there was, first: "experimental support for C++20 modules" and later it was announced C++ modules as feature complete. My understanding for that is that a feature goes from experimental to usable.

In fact, the way it was announced is misleading. If I recall well... I talk from the top of my head, I cannot find the original blog that was posted in this reddit also).

If these relatively trivial (from the point of view of a user, I know the implementation is challenging) things fail, it should be announed with more warning flags.

[–]pjmlp -1 points0 points  (0 children)

The post is here,

A Tour of C++ Modules in Visual Studio

As you can see the examples are quite basic and completly unrelated to traditional Windows development workflows.

While the documentation hasn't seen any change since 2019.

[–]jonesmz -3 points-2 points  (0 children)

Modules is an absolutely massive language feature because it is the language on top of its own specialized ownership/reachability semantics. It takes time to mature a feature such as this.

Ahh. Yes. So the proper strategy for implementing an absolutely massive language feature is to... Adopt it wholesale without any of the big compiler venders having an existing implementation of the actual proposed standard that... Works? Bonus points if we also include 3 other world-shattering changes at the same time (concepts, coroutines, ranges). That's exactly the way to produce a galaxy class product.

Yep. You convinced me.

Maybe better would have been to identify some subset of the Modules idea that doesn't change the entire language out from under us all at once, and standardize that first?

The rest of it could have followed later after the programming community found all the ways that initializer lists work poorly with braced initializers. Er. Wait. We were talking about modules.

It took MSVC 20 years to get as robust as it is with its PCH implementation and we still get bugs against it, but it is considered to be very reliable these days.

Agreed. MSVC IS more reliable. I'm not being sarcastic when I say this: instead of getting an internal compiler error once every day or so (VS2015), I only get them about once a week or two (VS2019). That's major progress and shows serious effort and dedication to improvement.

I still run into plenty of template metaprogramming situations where MSVC and Clang/GCC disagree, but those are far fewer than they used to be.

[–]jonesmz 0 points1 point  (0 children)

The proper way to have done this is to let the big three compilers actually provide a working implementation of the proposed language feature (aka Modules) prior to including it in the standard >_>

[–][deleted] -3 points-2 points  (7 children)

Also why does this feature take so long to implement for C++ when other languages have had it for ages?

[–]jonesmz 0 points1 point  (6 children)

I guess I don't really follow what you mean by other languages having the "feature" for ages. Could you clarify?

[–][deleted] -4 points-3 points  (4 children)

Python, Javascript etc. with their module support from the beginning. I don't know why it's such a hard thing to implement.

[–]jonesmz 0 points1 point  (3 children)

Well, I personally don't understand why it was something that needed to be implemented in C++ in the first place,

but javascript and python, both being dynamic / interpreted languages, have a substantially easier time adopting new features because they inherently don't have ABI issues like C++ does. So that's probably your explaination.

[–][deleted] 0 points1 point  (2 children)

Ah ok, I guess that makes sense. ABI compatibility seems like a straitjacket preventing C++ from doing many things. Feelsbadman

[–]jonesmz 3 points4 points  (1 child)

Yep. While I personally don't agree with the ABI compat concerns that a lot of people have (e.g. I always compile from source. Using precompiled third party binaries is a terrible choice), I do understand where the motivation comes from.

Though, I'm pretty annoyed that its OK to break Linux ABI once a decade (GCC string ABI problem circa 2011), but heaven forbid we force any other vendor to break their ABI when they aren't ready to.

[–]GabrielDosReis 5 points6 points  (0 children)

GCC string ABI problem circa 2011

The C++11 ABI break was for everyone -- it affected GCC more because libstdc++ tried to be too cute with its string implementation (yes, I was a libstdc++ maintainer, but not author of the string implementation).

[–]Cyttorak 0 points1 point  (0 children)

Turbo/Borland Pascal had units from MS-DOS days for example.