|
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
|
|
|
|
|
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 | [mastadon]](https://codeproject.freetls.fastly.net/script/Forums/Images/elephant.gif) you are doing.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: 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.
Yeah, I'm not sure on that either. It would seem that's the case. From what I've Googled the modules import stuff is already precompiled into a Abstract Syntax Tree (AST), which AFAIK is after the pre-processor kicks in.
Gary R. Wheeler wrote: For this reason it's frowned upon in more modern code.
Yeah, and don't get me wrong... I'm all about modern. But having the compiler make choices on your code before it gets compiled can be very useful... as we all know. Looks like the good must suffer with the bad. 
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
|
|
|
|
|
|
thanx will do
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
