|
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
|
|
|
|
|
|
I love that site. And yeah, that was my concern. It's usually the loudest voice that gets heard online, which may or may not be the actual truth of the matter. Question everything ya know. Don't get me wrong, it's cool that C++ is evolving... just want the truth of the matter to learn with.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: But, C++ modules... what's the big deal with them?
Seems like a really good question.
None of the replies that I have seen nor the links that I found actually answered the question as to why one would use them. Except for reduced compilation time. The links all go into depth on how to use them and the code for that but nothing about why a development show would use them.
Jeremy Falcon wrote: What's the benefit over using a static library with a pre-compiled header?
I wouldn't phrase it exactly like that. What is the advantage of these over a static library with a well defined (limited) public api which is exposed via an include file?
Presuming not much then, in that development shop, then managing modules as the same problem as the libraries. The process for delivering it into the rest of the applications would need its own process path (versions, builds, etc.) Not to mention correctly compartmentalizing the functionality. Seems like if a development shop already has that down then they might as well continue doing it that way. But then they might want to switch to modules.
But if the development shop does not have that process down then seems unlikely that this is going to help with anything.
|
|
|
|
|
formerly ,,, were under the delusion that we (Homo Sap) domesticated them [^]Quote: It also could be said that cats domesticated themselves; they were attracted to the rodents that feasted off the harvests of the earliest farmers. They chose us, not the other way around. In turn, those early farmers appreciated this welcome form of pest control. So, unlike dogs — which were domesticated earlier, initially for hunting — cats weren’t bred for various specific purposes. They arrived as a “ready-made” symbiotic species, so to speak.
Hail Bastet, Maneki-neko !
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Thousands of years ago cats were revered as Gods. We've forgotten, but they haven't.
|
|
|
|
|
Quote: Cats were not worshipped as gods themselves, but as vessels that the gods chose to inhabit, and whose likeness gods chose to adopt,” Skidmore explains. Through their ubiquitous presence in the art, fashion and home ornamentation of ancient Egypt, cats served as an everyday reminder of the power of the gods.
Did Ancient Egyptians Worship Cats? - HISTORY[^]
|
|
|
|
|
They were basically a living icon.
Also in the late period they killed huge numbers of cats to mummify, so they could deliver messages to a God for you. The number of cat mummies far exceeds the number of any other surviving ancient Egyptian object.
|
|
|
|
|
Still are, in our house 😸
Paul Sanders.
If I had more time, I would have written a shorter letter - Blaise Pascal.
Some of my best work is in the undo buffer.
|
|
|
|
|
Recent Maneki-neko appearance:
In the final couple episodes of Delicious Party Precure, maneki-neko from around the world fly to Oishiina Town to join the battle to rescue the world's food supply, helping the skyscraper-height maneki-neko statue that dominates the skyline.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
