I hope this isn't a programming question... (C++ Modules)
-
Well, I probably should've Googled a bit more. Came across a [better explaination](https://blog.ecosta.dev/en/tech/explaining-cpp20-modules) that, once you remove all the useless hoopla, said this:
Quote:
Before C++ modules, only one option was available: precompiled headers. They are not standard therefore results will vary depending on platform and compiler.
IMO that's the only valid argument for them. Everything else is a crap argument. Guess this is one area where MS was way ahead of the curve on. Note: I have nothing against modules. I'm just no longer fooled by hoopla. Decades of coding will do that to you.
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](https://developercommunity.visualstudio.com/t/forward-declarations-in-module-partitions-are-trea/1648091.)
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
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. :-D
Jeremy Falcon
-
I'm not asking how to codez teh homework, and I'm looking for more theory. But, if this seems like a programming question, then just downvote this sucker and give me angry emojis. :-O But, C++ modules... what's the big deal with them? In JavaScript/ECMAScript it's a huge deal because prior to modules the best we had was clumsy hacks to workaround lack of support for separating code. But, in C++... I don't get it. What's the benefit over using a static library with a pre-compiled header? This one of them things where history just repeats under a new name so younger devs feel like there's change when there's really not? Or is this a marketing thing where C++ is trying to play like the new, cool kid on the block too? Edit: Also, when did using the pre-processor become discouraged in C++? I never understood the disdain for that (assuming you don't go too crazy with macros like the Win32 API does). Years and years of C coding and I never once ran into an issue because of the pre-processor, so generally I just chalk that up to people wanting to sound fancy by insulting things they have little concept of.
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
-
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
-
Well, I probably should've Googled a bit more. Came across a [better explaination](https://blog.ecosta.dev/en/tech/explaining-cpp20-modules) that, once you remove all the useless hoopla, said this:
Quote:
Before C++ modules, only one option was available: precompiled headers. They are not standard therefore results will vary depending on platform and compiler.
IMO that's the only valid argument for them. Everything else is a crap argument. Guess this is one area where MS was way ahead of the curve on. Note: I have nothing against modules. I'm just no longer fooled by hoopla. Decades of coding will do that to you.
Jeremy Falcon
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.
-
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
-
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
-
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
-
I'm not asking how to codez teh homework, and I'm looking for more theory. But, if this seems like a programming question, then just downvote this sucker and give me angry emojis. :-O But, C++ modules... what's the big deal with them? In JavaScript/ECMAScript it's a huge deal because prior to modules the best we had was clumsy hacks to workaround lack of support for separating code. But, in C++... I don't get it. What's the benefit over using a static library with a pre-compiled header? This one of them things where history just repeats under a new name so younger devs feel like there's change when there's really not? Or is this a marketing thing where C++ is trying to play like the new, cool kid on the block too? Edit: Also, when did using the pre-processor become discouraged in C++? I never understood the disdain for that (assuming you don't go too crazy with macros like the Win32 API does). Years and years of C coding and I never once ran into an issue because of the pre-processor, so generally I just chalk that up to people wanting to sound fancy by insulting things they have little concept of.
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.
-
I'm not asking how to codez teh homework, and I'm looking for more theory. But, if this seems like a programming question, then just downvote this sucker and give me angry emojis. :-O But, C++ modules... what's the big deal with them? In JavaScript/ECMAScript it's a huge deal because prior to modules the best we had was clumsy hacks to workaround lack of support for separating code. But, in C++... I don't get it. What's the benefit over using a static library with a pre-compiled header? This one of them things where history just repeats under a new name so younger devs feel like there's change when there's really not? Or is this a marketing thing where C++ is trying to play like the new, cool kid on the block too? Edit: Also, when did using the pre-processor become discouraged in C++? I never understood the disdain for that (assuming you don't go too crazy with macros like the Win32 API does). Years and years of C coding and I never once ran into an issue because of the pre-processor, so generally I just chalk that up to people wanting to sound fancy by insulting things they have little concept of.
Jeremy Falcon
Using header files the interface to the library can compile differently to how the library itself was compiled, usually depending upon preprocessor definitions and that sort of thing. My impression is that C++ modules guarantee that the user of a library sees the same interface, types, etc. that the compiler of the library saw.
Jeremy Falcon wrote:
when did using the pre-processor become discouraged in C++
I have a feeling some of this can be attributed to the open source movement. Preprocessor use is a 'code smell' in some circles, and its a metric that can be easily applied to an arbitrary body of code. There are probably tools out there to help you choose between open source packages based on certain metrics, including this one. The preprocessor has a history of being abused, creating inadvertent side-effects and difficult to find bugs. For this reason it's frowned upon in more modern code. These prejudices ignore the cases where the preprocessor is used to simplify syntax, reduce ceremony, etc. and you know what-the-:elephant: you are doing.
Software Zen:
delete this; -
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! :laugh: :laugh: :laugh:
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
I'm not asking how to codez teh homework, and I'm looking for more theory. But, if this seems like a programming question, then just downvote this sucker and give me angry emojis. :-O But, C++ modules... what's the big deal with them? In JavaScript/ECMAScript it's a huge deal because prior to modules the best we had was clumsy hacks to workaround lack of support for separating code. But, in C++... I don't get it. What's the benefit over using a static library with a pre-compiled header? This one of them things where history just repeats under a new name so younger devs feel like there's change when there's really not? Or is this a marketing thing where C++ is trying to play like the new, cool kid on the block too? Edit: Also, when did using the pre-processor become discouraged in C++? I never understood the disdain for that (assuming you don't go too crazy with macros like the Win32 API does). Years and years of C coding and I never once ran into an issue because of the pre-processor, so generally I just chalk that up to people wanting to sound fancy by insulting things they have little concept of.
Jeremy Falcon
-
Are C++ templates just forms of macros or are they more? They look like macros. I don't use them just trying to understand them.
"A little time, a little trouble, your better day" Badfinger
They are not macros. They are far more powerful. Perhaps start at [Template metaprogramming - Wikipedia](https://en.wikipedia.org/wiki/Template\_metaprogramming)
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
They are not macros. They are far more powerful. Perhaps start at [Template metaprogramming - Wikipedia](https://en.wikipedia.org/wiki/Template\_metaprogramming)
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
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.
-
I'm not asking how to codez teh homework, and I'm looking for more theory. But, if this seems like a programming question, then just downvote this sucker and give me angry emojis. :-O But, C++ modules... what's the big deal with them? In JavaScript/ECMAScript it's a huge deal because prior to modules the best we had was clumsy hacks to workaround lack of support for separating code. But, in C++... I don't get it. What's the benefit over using a static library with a pre-compiled header? This one of them things where history just repeats under a new name so younger devs feel like there's change when there's really not? Or is this a marketing thing where C++ is trying to play like the new, cool kid on the block too? Edit: Also, when did using the pre-processor become discouraged in C++? I never understood the disdain for that (assuming you don't go too crazy with macros like the Win32 API does). Years and years of C coding and I never once ran into an issue because of the pre-processor, so generally I just chalk that up to people wanting to sound fancy by insulting things they have little concept of.
Jeremy Falcon
-
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
not all heroes wear capes.
CI/CD = Continuous Impediment/Continuous Despair
-
Well, I probably should've Googled a bit more. Came across a [better explaination](https://blog.ecosta.dev/en/tech/explaining-cpp20-modules) that, once you remove all the useless hoopla, said this:
Quote:
Before C++ modules, only one option was available: precompiled headers. They are not standard therefore results will vary depending on platform and compiler.
IMO that's the only valid argument for them. Everything else is a crap argument. Guess this is one area where MS was way ahead of the curve on. Note: I have nothing against modules. I'm just no longer fooled by hoopla. Decades of coding will do that to you.
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 :laugh:
-
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
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.
-
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. :laugh:
Jeremy Falcon