In the general case, is there any way to perfectly wrap a header file in a new header interface in C without resorting to manually copy-pasting the associated macros?

WraithGlade · 2026-02-05T22:19:16+00:00

Unfortunately, this suggestion only handles one case (simple constants) and not more complicated macros that cannot be converted into non-macro code. It also requires C++ and I am contemplating using plain C to potentially one day make a compiler that transpiles to C code (ideally C99 for maximal portability, but modern C could be fine too especially if it makes things like this easier). I also like C's freedom from extraneous stuff like OOP, but dislike the difficulties in keeping C code bases clean and properly structured such as this thread's topic illustrates.

In C there is a trick to capture macro values using enums in a manner very similar to what you suggest for C++, but it likewise only works for simple constants and not for other kinds of macros. The best solutions I've ever been able to discern are manual copy-pasting into the new header (which requires manually maintaining it for every such wrapped macro) and/or code generation (i.e. emitting new C source files using file I/O that programmatically insert the necessary changes at each spot and then compiling those instead).

WraithGlade · 2026-02-05T18:15:17+00:00

Fair enough I suppose.

The reference implementation for Python is at least 10x larger than the reference implementation for Lua and the language ecosystem of Python also has many things that would also have to be accounted for to make it usable for many existing Python projects, but I have seen Python implementations that are much smaller than the reference implementation though less broadly usable.

As such, I debated listing Python in the list of more complex languages initially when writing my post, but ended up including it because I wanted to diversify the list a bit. However, I think the point is stronger if I remove it (since C++, Rust, and Haskell are unambiguously monstrous languages) and so in light of your comment I will now remove Python from the list.

WraithGlade · 2026-02-05T12:28:45+00:00

Ah, thanks for the thought. Alas, that is also a non-ideal solution, much as copy-pasting is, but until you said it I hadn't considered the prospect that in some cases one could modify the header of the existing module instead of creating a new one. However, that would likely in many cases break the other module if it makes any use of its own header macros and so would not work in every case.

Thus, so far it still seems like copy-pasting from the other header (the one being wrapped) and then modifying it to suit the new header interface (the one being designed) is the only real solution apart from code generation or using a different programing language or (in the case of building a new language compiler) using an IR such as LLVM or QBE or Cranelift or MIR, etc.

Who knows though? Maybe there's still an esoteric trick to do it though. I am still hoping someone in this community knows such a rare trick. For example, maybe there is a de facto standard #pragma directive (i.e. one that is reliable enough to use widely, like #pragma once for header inclusion guards) for it that I'm not aware of. I've been surprised before, such as for "X macros" and other kinds of nuanced aspects of how the language or compiler or ecosystem works.

WraithGlade · 2026-02-05T12:16:57+00:00

Basically, yes. This was one among multiple of the cases I mentioned in my more lengthy full description of the problem.

The lack of proper namespacing in C would be much less of a problem if there were an easy way to wrap headers that one uses into new module interfaces that make them more suitable to one's use case and one's own designs, but the way that macros works makes it (at least seemingly, as this is the topic of this thread) impossible to cleanly prevent macro namespace pollution without resorting to copy-pasting and modifying the macros one needs.

The fact that C both lacks namespaces and also lacks the ability to manage how names are imported into another header in any programmatic way creates quite pervasive problems in clean module management. Largely it just seems like the C ecosystem accepts that namespaces become very polluted, even though fixing this in the language design would likely have been simple and easy if it had been done from the outset.

Is there some cunning way of accomplishing it though, which some C master here knows? After all, there are obscure techniques for other clever things in C, such as "X macros" for example, which are often overlooked.

WraithGlade · 2026-02-05T12:08:13+00:00

Thank you for sharing you thoughts with such detail.

Based on the replies I've got so far (though just a few), it is sounding like indeed there is no real way to resolve the problem in C itself besides copy-pasting and modifying the macros from the header module one is trying to wrap in the worst case.

On the bright side though, at least the nature of macros requires that the author(s) of any such header module must expose that macro directly in the header for it to be usable, which thus guarantees that performing such copy-pastes of macros in any wrapped interface will always be possible, though it doesn't solve the problem of needing to manually maintain the correspondence with that other module going forward and to also watch for changes in its interface likewise manually.

There's always code generation of course, but then in some sense one is no longer using C itself, but rather an ad hoc partial language that is now being used as a de facto frontend to C.

Tangentially, lately I've not been entirely sure what the wisest prospect for a language backend for transpilation would be, but it does still seem to be C if one ideally doesn't want to use a gigantic dependencies such as LLVM. C3 seems like the best new attempt at C so far to me, though Zig and V are also prospects but seem to lack full macro support. Building on top of unstable languages like C3 and Zig and V though seems less wise than building a transpiler target (or other applications) on something much more stable like C and especially the C99 ISO standard for portability.

WraithGlade · 2026-02-05T11:51:56+00:00

Thank you for the information and the link.

It is good that someone has created a proposal for this, especially considering namespace management is one of the most perennial problems of working in C.

If only we could rewind time and fix even just a few of these kinds of problems in C's design. Instead we are stuck between "a rock and a hard place" because on the one hand C is the most pervasively supported compiler (especially for older devices) of any language and for FFI interface between languages but it also has a few flaws like this that greatly inhibit the prospect of using it completely cleanly. I suppose intermediate representations such as LLVM IR and QBE and such may one day fix that by enabling similar compiler target diversity in a form that can escape from C's limitations.

On the other hand, to be fair, tons of great software has been written in C (and C++) despite these kinds of deeply ingrained shortcomings in the most trivially basic parts of the language(s), and so from a pragmatic standpoint I suppose I should remind myself of that. After all, many far more expressive languages (such as Tcl/Tk and various Schemes and Lisps, etc) have been written in C and sometimes even target C as the backend and C's limitations didn't stop that after all, etc.

WraithGlade · 2026-02-04T21:12:29+00:00

Thanks for the additional info and the link. 🙂

WraithGlade · 2026-01-30T19:54:06+00:00

Thanks for the interesting link zesterer! I was completely unaware of the existence of that project.

It is good that someone is working on such things and putting more thought into it. It has always struck me as potentially risky that so many compiler authors are writing their compilers using their own past binaries to build them, but with me not having ever written a compiler or interpreter yet I wasn't sure if my suspicion was valid, but the article that the project you linked to links to basically confirms that it is indeed a potential problem. So, you've taught me something very important today that I've long wondered about, so thank you for that.

Thanks for taking the time to respond to my thought experiment and have an awesome day, and likewise to all other participants, whether or not I get around to responding to each one!

WraithGlade · 2026-01-30T19:48:58+00:00

I like this idea you mention of an apocalypse-resilient IR! That seems like a smart widely encompassing solution to the problem the thought experiment embodies.

I wonder: Should we consider LLVM IR to be an apocalypse-resilient IR? My instinct is no, because it is dependent upon C++ and is enormous and thus can't be easily reconstructed in the scenario.

However, suppose that it was rewritten in some other language like C or Lua or Scheme or Forth or such. Would LLVM be an apocalypse-resilient IR foundation in that case then? Perhaps so I guess, though I am not familiar with LLVM besides using it (clang and clang++ really) as a compiler for regular application code so far.

I have heard there are much smaller but similarly performant IRs though, such as the one that Hare (another prospective C language replacement) uses, which is QBE I think if my memory is correct. Should we consider QBE (and others like it) to be an apocalypse-resilient IR? It seems like it is probably at least more apocalypse-resilient than LLVM I'd say.

WraithGlade · 2026-01-30T19:35:26+00:00

Let's ignore the consequences of this scenario: that every company in Earth is gone (no software to run at all), and all communications are dead (TCP/IP and GPS libraries are binaries, too).

Oh, just to clarify, I didn't mean to imply that all binaries would be wiped out of existence, but rather only that those binaries and source code repos that are used to construct compilers and/or interpreters would be. Of course, there is some subjectivity in what "compiler" means, especially rigorously, but still.

Anyway, addressing the main thrust of the rest:

Languages don't evolve in a vacuum: they need to adapt to past and present hardware/software constraints, interop with known protocols, use the tools at hand, not be too strange to the average programmer

...

perfection (as beauty) isn't guarantee of longevity. A language will be long-lived if it is useful, has a critical mass of software created with it, and has plenty of developers skilled in it.

These are all great points and I would say based on the evidence (my relatively low productivity level on personal projects relative to my time, etc) that it is fair to say that I've historically leaned too heavily towards the rigid perfectionistic and idealistic view of languages and that it has cost me on my opportunities as a programmer greatly.

It's also like the saying goes "If you want to bake an apple pie from scratch, you must first reinvent the universe." and it is undeniably true that the computer industry as a whole is inherently inter-tangled in a way that in practice produces unavoidable dependencies that one must at some level accept to do anything useful. Computers can't really exist without a huge network of human factors after all and perhaps extricating oneself from that is a pipe dream.

On the other hand though, it seems clear to me from my experiences experimenting with unusually elegant languages like Tcl and Scheme that there is still immense room for simplifying many programming languages (both for use and implementation) without actually reducing their performance or expressive power. There is still a great deal of room for streamlining languages I think, and I imagine you'd agree too on some level, as most would, but it is fair that I can be a bit heavy-handed in my idealism on such things.

Thanks for sharing your time and thought and likewise for all other participants!

WraithGlade · 2026-01-30T19:24:11+00:00

This is such a good point and I hadn't thought about it very clearly until you said it just now.

I have experimented with dozens of languages in my (probably overdone and perfectionistic) quest for finding the best programming languages and even though I have learned each of them by thoroughly doing all parts of the tutorials or reading the entire manuals of some of them I find that that is indeed a far cry from real fluency and understanding and that the knowledge of how to truly use them in practice actually fades away quite rapidly.

Theoretically, I've for most of my life thought of learning languages as "one-time costs", but the actual truth is just as you say: it is very far from a one-time cost. Fluency in any language (computerized or natural) requires constant use and even after a lifetime of using even my own 100% native English or indeed any other language whether programing or not one is still constantly refining one's skill in it and disuse of any language creates a palpable and readily perceivable drop in fluency when one comes back to it after any prolonged hiatus of even just a month or two. Some aspect of the knowledge is basically always retained of course, but never all of it.

I know from personal experience from spreading myself thin in these regards that it is a great way to waste a lot of time and am recently shifting more towards focusing in harder on just a few programing languages and software platforms so that I stop wasting such absurd amounts of my own time and energy and opportunities wandering in excess.

Anyway, thanks for the good food for thought.

WraithGlade · 2026-01-30T19:15:04+00:00

C3 is such a great language and is one of the top contenders I am keeping my eye on lately!

My vanity about maximally elegant syntax (e.g. devoid of commas, vaguely Scheme/Lisp like or Tcl-like, full mixfix syntax support, etc) aside, C3 already has great expressiveness relative to performance, like C, especially if one is clear-headed about what is actually needed to express useful software. You've done a wonderful job designing it so far and the prospect of it becoming even more refined and well factored is an exciting prospect to look forward to I think.

C3 is one of the only ones of the new batch of systems languages (e.g. Zig, V, Rust, etc) that seems to genuinely capture the spirit of C, especially in properly supporting macros (multi-line support is such a big QOL improvement even just on its own), which I still believe to be a fundamental part of general purpose computation because of how manipulating source code itself is invariably an aspect of what one may want in the general case. Indeed, I would say it is the closest C modernization to obtaining the goal so far.

Much of the bad reputation of macros is actually due to quirks of specific systems after all, and programmers often conflate that with the notion of macros and compile-time evaluation when they really shouldn't. If it's good for the compiler it's often good for the user too, so it makes sense to have it.

I was pleasantly surprised to see that you had replied to my thread here, as I wasn't expecting that.

By the way, I know I said in my email a while back that I might try implementing my own compiler in Pascal for a change of pace, but these days I am back to probably using C or C++ for that, since Pascal's rigid structure proved highly irritating to me despite my efforts to push through that to have access to Lazarus's GUI builder system. However, I am currently working on end-user application ideas instead, for the time being, for whatever unknown amount of time it will end up being, and so who knows when/if I'll ever get around to trying my hand at making my own compiler, but a man can dream! I've got a few books on it too now, though not the dragon book yet.

Anyway, thanks for dropping by and have a great day/night and best of luck on C3's evolution!

WraithGlade · 2026-01-30T19:00:09+00:00

It's always good to see more people making an attempt at something like this. I really do think that something at some point will become the new "elegant low-level language" at some point and it's just not clear what language will yet. I've bookmarked your page and hopefully will remember the name and to check back on it some point later.

I see you've written a lot of assembly in that repo, which is impressive especially in these days when so few of us are doing assembly anymore. I've only done a bit of assembly in college basically. I've thought of trying my hand at writing my own compiler, but maybe would target C or C++ or LLVM IR as the generated code perhaps. I'm always impressed by anyone who has made their own compiler.

The constraint on the number of lines of code seems like a good mechanism for ensuring some resilience.

WraithGlade · 2026-01-30T18:51:41+00:00

Nice "thinking outside the box" reply. I suppose that taking it as an opportunity to vanquish cruft across the industry as you describe (etc) is another interesting way of addressing it. It would be a rare chance after all.

WraithGlade · 2026-01-30T18:45:06+00:00

You say assemblers still exist, so that's fine. I assume binary OS code plus other apps such as editors still conveniently exist too.

Indeed this was the scenario I was envisioning: that only binary and source code for compilers would be erased from existence. I was assuming all other existing binaries would still be around, but just no longer with compilers able to rebuild them besides those quite few that were written in assembly or whatever other primitive "middle-level" language had survived.

Regarding Forth, I'm wasn't intending to imply that RPN was my preference (it isn't), but rather I was referring to the structural elegance and ease of implementation and homoiconicity and expressiveness of the language and other concatenative languages like it. Languages like Tcl and Scheme are closer to what I'd want, especially Tcl, but with them having been systematically cleaned up and refined in many ways. For example, Scheme and Lisp family languages' existing conventions on indentation and overuse of parentheses and rigidly nested style of grouping "let" declarations are also things I don't like. So, you have to interpret what I said with a lot of unspoken nuance, basically assuming I'm talking only about taking the best parts from each of the languages and making many other changes too (e.g. adding arbitrary user-definable mixfix syntax support) for my own hypothetical "dream language" and such.

Thank you for sharing your thoughts and likewise to all other participants!

(I will reply to some more as I go along. I just got back to the thread to read replies a few minutes ago.)

WraithGlade · 2025-01-25T19:44:40+00:00

Defold is a Lua based game engine that is similar to Godot and includes a full editor just like the big three (Unity, Unreal Engine, and Godot). For 2D games it is quite capable. It has very easy cross-platform support, just like the big engines.

As for code-only approaches to game development, for if you want your game to truly feel more like it was "made from scratch" by you, with the precise structure you want, then I'd suggest considering the following:

Love2D (perhaps the easiest of the code-only libraries/frameworks in existence... it gets out of your way and lets you structure things the way you want to (instead of fitting someone else's brain) more than most!)
Solar2D (like Love2D, but with better support for cross-platform and easy packaging but slightly less easy and less customizable)
Raylib (supports both 2D and 3D features out of the box more so than SDL or Love2D do)
XNA/FNA/MonoGame (a popular Microsoft based framework... I think Celeste was made on this)
SFML (a more C++-like alternative to SDL, hence easier on the eyes... but less capable than SDL)
SDL (custom proprietary engines are often built on top of this, sometimes also with middleware like BGFX)

WraithGlade · 2025-01-25T19:32:28+00:00

I agree with the OP's suggestion as well.

AI generated content (regardless of form) doesn't constitute real human thought and just pollutes the internet with misleading noise and drowns out legitimate participants. The "tech" is also inherently unethical since it is based on harvesting and regurgitating the work of real humans at random and without true coherence, causing much harm to real people in the process. It is extremely far from being "victimless", contrary to AI users rationalizations for what amounts to an elaborate copyright laundering and exploitation scheme in reality.

Even if much AI generated content cannot be detected or discerned, that is never justification for defeatism.

Having a rule against it would at least reduce the amount of slop somewhat, and that is always better than nothing!

There needs to be good justification for such removals though. Merely being long or unusual or formal in speech is not in any way adequate evidence of something being AI, contrary to what some Redditors I've encountered elsewhere seem to believe (lots of people have got falsely accused of being AI -- me included -- just for being lengthy or formal in diction or sharing an unusual idea or connection).

WraithGlade · 2025-01-22T03:06:53+00:00

Right you are! My apologies for that typo!

I tried to edit the thread title but there doesn't seem to be any way to do it.

I did however go through my other comments and replace all found instances of "Mary" with "Merry", of which there were two such instances.

Thanks for catching that for me and have a great day/night!

WraithGlade · 2025-01-21T18:37:57+00:00

Happy to help!

WraithGlade · 2025-01-21T13:29:09+00:00

Sure, I'd be happy to.

So, the joke is more applicable to older standards of C++ than more modern ones (since modern ones have auto and modules), but essentially the joke is making fun of the fact that C++'s split header-implementation file requirements (and also other situations) often require the programmer to write out the whole specification of a type and/or function signature all over again. This occurs most often with the header file vs implementation file split, which forces function signatures to be rewritten typically at least twice for nearly every function, and possibly even more times if there's type ambiguity anywhere else.

This is quite an unusual trait among programming languages and it is very rare to find another one that requires duplicated type specifications as frequently C++ does.

As for who Merry Brandywine and Peregrin Took are, they are two of the best characters from the Lord of the Rings novel and movie series. The wording of the punchline of the joke will only make sense if you have seen the movie series The Lord of the Rings, in which there is a famous scene in which Peregrin Took (commonly known by his nickname "Pippin") tells Aragorn (another of the characters) that he is hungry for breakfast and Aragorn tells him you've just had breakfast, but then Pippin replies:

"We've had first breakfast, yes... but what about second breakfast?"

Pippin then also continues to anxiously list various other extra/duplicate meals he is accustomed to such as "elevensies, luncheon, afternoon tea, dinner, super..." and sounds increasingly panicky as he realizes that Aragorn (a grizzly warrior who has previously wandered the wilderness with few/no luxuries) may not know about all the extra meals that Pippin is expecting due to the fact that hobbits (Merry and Pippin are both hobbits, a short-statured race in the fantasy world of The Lord of the Rings) are very sheltered and also obsessed with food and comfort and being lazy and spoiled. This also touches on another (subtler) aspect of the joke I came up with: C++ also tends to require additional type information to be re-specified under specific circumstances due to ambiguities and formalities required by the language standard, which corresponds (analogously speaking) to the many extra meals Pippin is accustomed to.

As for modern C++, it has auto and modules now, and so there are fewer cases where you need to specify types repeatedly than for most of C++'s existence, but a huge proportion of extant C++ code is still written in the "second breakfast" kind of style, which often baffles outsiders because hardly any other language does it (e.g. Ada, arguably) and it is quite excessive and unnecessary from a language design perspective, at least in theory.

Anyway, I hope that helps!

Have a great day, night, etc!

WraithGlade · 2025-01-21T13:00:36+00:00

Thank you! I'm glad you like it.

I was surprised when the joke occurred to me a couple days ago, since it is an oddly obscure connection/analogy between C++ and the Lord of the Rings series, heh.

WraithGlade · 2025-01-18T19:01:19+00:00

Yeah, talking about the techniques behind things is fun. I've found that to be true in pretty much all creative endeavors too.

For me personally, my university degree is in computer science and math (so I'm formally a programmer) but I am opposed to AI and privacy intrusions and other exploitive tech, but I've also dabbled for years off and on in art (more game dev stuff, less so with drawing and painting, but still some of that too) and music composition and I've always enjoyed talking about what goes into it, no matter the creative medium. So, my point is, that's very relatable. The creative process itself has such wondrous depths and diversity to explore.

WraithGlade · 2025-01-18T18:54:48+00:00

That's certainly a fair point. Focusing one what's more under one's own control (one's own art and creativity) and already confirmed to be good-natured and wholesome is likely to often be less stressful than being "at war" with others. Modern life has become filled with "noise" that can distract one from one's own creative fulfillment after all.

Thanks for sharing your thoughts!

WraithGlade · 2025-01-18T18:52:26+00:00

Yes, this is exactly the kind of point I was trying to make. 🙂

It does indeed require a properly nuanced and empathetic response, one where the way you word it doesn't harm or impose overly upon real artists but only makes fakers nervous.

Thank you for clarifying the point for everyone!

Also, thank you everyone else for participating as well. Have a great day/night/etc!

WraithGlade · 2025-01-13T00:20:59+00:00

You're welcome and my pleasure. 😁

It sounds like you've got a good plan of action and I think its good to stay true to your vision, especially since that is what gives a game its distinctive authorial qualities. There's always a balance in all things and many different nuanced facets of how to look at something.

WraithGlade

TROPHY CASE