|
The idea is not bad. But as far as I know there is not yet a standard defined and google and MS do it in a different way
|
|
|
|
|
0x01AA wrote: The idea is not bad Yeah, at its core I think it's nice to standarize this. Not trying to sound poopy, just trying to get to the truth without hoopla is all.
0x01AA wrote: But as far as I know there is not yet a standard defined and google and MS do it in a different way This is makes me laugh. That twisted sense of humor kicking in.
Jeremy Falcon
|
|
|
|
|
Note that VS has one problem with modules that is worth being aware of: forward declarations. I reported this a year ago, and it would be nice to see it fixed: Visual Studio Feedback
|
|
|
|
|
Jeremy Falcon wrote: Before C++ modules, only one option was available: precompiled headers. That was never true and is even less so now. Precompiled headers just allow compilations to run a bit faster, but they were never mandatory, and are probably less valid with modern high powered systems.
|
|
|
|
|
Richard MacCutchan wrote: That was never true and is even less so now. How so? AFAIK there was no other pre-compiled mechanism for removing header compilation prior to PCH.
Richard MacCutchan wrote: Precompiled headers just allow compilations to run a bit faster, but they were never mandatory, and are probably less valid with modern high powered systems. This is missing the point. Nobody said PCH was mandatory. We're talking abstract concepts here, a bit higher level than this.
Jeremy Falcon
|
|
|
|
|
Maybe I missed the point you are trying to make.
|
|
|
|
|
More like trying to understand what the big deal is, not that I have anything against them in theory. But to me, it seems they may add a slightly better way of doing things, but it's not Earth shattering like it was for JavaScript/ESM as C/C++ had more than one way to split and re-use code before this.
I'm a cranky, old-ish fart. So, ya know, want to get past the fluff I've seen on Google so far and get straight to the real talk as I inquire about them.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: I'm a cranky, old-ish fart. You don't know what old is sonny. My youngest son is eight years older than you, and my eldest grand-daughter only ten years younger.
But thank you for the clarification above; it's something I need to learn more about.
|
|
|
|
|
Richard MacCutchan wrote: You don't know what old is sonny. Touché.
Richard MacCutchan wrote: it's something I need to learn more about. Me too. I think C++ evolving is cool. I'm just to that point in life I need more than fluff or hyberpole to listen to something. Which after a quick Googling was all I found. So, ya know... bug CP about it.
Jeremy Falcon
|
|
|
|
|
"Before C++ modules, only one option was available: precompiled headers. They are not standard therefore results will vary depending on platform and compiler."
Finally, someone explains it to me.
And it seems I don't need to use modules then (unless someone only publishes a library that way)
But I was never a big fan of PCH (I never put compilable code in them anyway). Growing up with C/C++ (and then assembler) on everything from DOS to embedded systems, I never saw the need to question how includes and linking worked. I was always more worried about getting the smallest and fastest executable code possible (which VS is notorious for injecting useless junk into) and if it meant using obscure/esoteric techniques from ancient Unix, so be it.
I am aware that the linking system inherited from C has something to do with being able to link to Fortran object code...I think it's high time I abused that ancient caveat
|
|
|
|
|
Yeah, agree on all fronts. And I also don't have anything inherently against modules either. But if, like us, you've been around the block... we need more substances than hoopla or hyperbole to accept things.
Juan Pablo Reyes Altamirano wrote: I am aware that the linking system inherited from C has something to do with being able to link to Fortran object code...I think it's high time I abused that ancient caveat That's cool to know. Thanks.
Jeremy Falcon
|
|
|
|
|
I don't know about modules; in my current job/career path, I will probably never use them.
But about the pre-processor thing ... I think it was just abused too much at some point and became a mess; there are just better way to do the same thing with modern language features.
It's the same thing with goto, in itself it's not bad, but when it's badly used, can be a big problem (resource leak, safety issues, ... )
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Maximilien wrote: I think it was just abused too much at some point and became a mess; there are just better way to do the same thing with modern language features. Fair enough, and I can see that too. The good must suffer with the bad.
As a joke, once a buddy of mine decided to use macros to give C a Pascal-like syntax. It was a joke though, but some people would be like..... noice.
Jeremy Falcon
|
|
|
|
|
It would be even noicer if he created a parser/lexxer from scratch using that Pascale-like syntax! Full-circle of madness!
|
|
|
|
|
not all heroes wear capes.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
|
In the ‘70s, we wrote a PL/1 BNF parser to update Fortran to Fortran77. It soon became apparent that it would be easier to enhance if we wrote it in itself, and someone immediately wrote the inverses to check both. That did it. Soon there was a competition to create the longest loop through the most languages to produce functioning code, with extra points for generating similar code with the same variable names. The project was still going in late ‘82 when I left.
|
|
|
|
|
Noice. That's cool.
Jeremy Falcon
|
|
|
|
|
I haven't graduated to C++20 yet, so I won't comment on modules.
You haven't run into issues with the preprocessor?
I tried to compile my embedded streams library for an older platform.
It failed because on my virtual classes i had functions like getc and putc. Shouldn't be a problem, right?
Wrong.
Because somebody decided to take every C library function and wrap it with a macro, such that getc was #define getc __getc or some garbage like that.
Also scope pollution. The struggle is real. There is no way to control scope with macros, meaning I avoid them like the plague except for as configuration options (allowing them as part of the build scripts) and in implementation C/CPP files where they won't pollute the global namespace.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: Because somebody decided to take every C library function and wrap it with a macro My C is way stronger than my C++, but I don't see how that would cause an issue in and of itself, virtual base class or otherwise. AFAIK there's no C++ convention causing virtual classes to bomb just because a standard c function was used in a macro, no? Not suggesting that's clean code either. Just don't see where that by itself would cause a compile error.
honey the codewitch wrote: Also scope pollution. The struggle is real. There is no way to control scope with macros I can see that. Since I do a lot more C than C++, it's mostly convention over language feature for handling this kinda stuff. So as long as your conventions are good you can usually fake scope by using prefixes in your names. Which, while isn't pretty, works. To me, it's blaming the tool for crappy programmers not using the tool. Such is life though.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: I don't see how that would cause an issue in and of itself, virtual base class or otherwise.
Because you're using a macro to literally rename the function on the class. It then becomes __getc which is a disaster.
Jeremy Falcon wrote: Which, while isn't pretty, works. To me, it's blaming the tool for crappy programmers not using the tool.
For one thing, I believe it should be easiest to do the right thing.
For another the problem with preprocessor scope is the same as it is with global vars. To ensure non conflicting macros you have to make them very long.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Quote: Just don't see where that by itself would cause a compile error.
Macros are very dumb search and replace. No context from the language.
Thingy->getc(678)
Precompiles to
Thingy->__getc(678)
|
|
|
|
|
englebart wrote: Macros are very dumb search and replace. No context from the language. Which is exactly that in and of itself wouldn't cause an error... because all it is, is a replacement.
Jeremy Falcon
|
|
|
|
|
It failed because on my virtual classes i had functions like getc and putc. Shouldn't be a problem, right?
Wrong.
Because somebody decided to take every C library function and wrap it with a macro, such that getc was #define getc __getc or some garbage like that.
max and min are like that. My code is peppered with
#undef max
#undef min
just because a certain OS platform decided to define these as macros.
|
|
|
|
|
I mean, I guess I get it. This is usually done on C only platforms, and the problem crops up with classes.
However, in the year 2024 people should realize that you're going to run C++ on some of these platforms. They need to be updated.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|