Macros on Steroids: How pure C can benefit from metaprogramming

Re:Macros on Steroids: How pure C can benefit from metaprogr... by Hirrolot on Thursday July 22, 2021 @01:48PM (#27922028)

There are several reasons why not to resort to third-party code generators [1]. This includes the burden of maintenance (think about the build process) and seamless integration of native macros with other code.

Do you have some code to show bloated binaries with Datatype99/Interface99? The last time I checked the generated assembly code, it was nearly of the same size as hand-written code [2].

[1]: https://github.com/Hirrolot/metalang99#q-why-not-third-party... [2]: https://godbolt.org/z/ns6Ma7csd

[ Parent | on HN ]

Re:Macros on Steroids: How pure C can benefit from metaprogr... by Banana699 on Thursday July 22, 2021 @05:01PM (#27924286)

Original comment was satirizing C++, it started as a (relatively) simple code generator that consumed a custom OOP variant of C and produced pure C. It grew into... well C++.

[ Parent | on HN ]

Re:Macros on Steroids: How pure C can benefit from metaprogr... by pjmlp on Friday July 23, 2021 @02:16AM (#27927762)

Complex as it may be, I doubt anyone will be answering every pub quizz questions about C# 10, Java 17, Python 3.9, TypeScript 4.4, ....

[ Parent | on HN ]

Re:Macros on Steroids: How pure C can benefit from metaprogr... by IncRnd on Thursday July 22, 2021 @03:02PM (#27922855)

Thank you. I wasn't talking about what you mentioned. Cfront was the preprocessor that implemented c++ for the first decade of its existence.

[ Parent | on HN ]