Live data from Hacker News

Recursive macros in C, demystified (once the ugly crying stops)

h4x0r.org

61–70 of 90 posts

Re: Recursive macros in C, demystified (once the ugly crying stops)

#61
post #44

In many ways being limited ends up being a feature. Even limited as it is, you get some crimes against humanity like the bourne shell source, but at least most people agree it is a bad idea If it allowed more unlimited metaprogramming, building big complex things as macros might well have become popular

The CPP does allow quite advanced metaprogramming, it's just so obtuse to use and requires insane hacks so almost nobody does. See one of my favorite projects https://github.com/hirrolot/metalang99

The CPP allows “advanced metaprogramming” like throating a banana can sometimes sound like speech

Re: Recursive macros in C, demystified (once the ugly crying stops)

#62
post #7

The behavior of C macros is actually described by a piece of pseudocode from Dave Prosser and it is not in the standard: * https://www.spinellis.gr/blog/20060626/ * https://www.spinellis.gr/pubs/jrnl/2006-DDJ-Finessing/html/S... * https://gcc.gnu.org/legacy-ml/gcc-prs/2001-q1/msg00495.html

This is the best explanation I've seen so far: https://marc.info/?l=boost&m=118835769257658&w=2

[deleted]

Re: Recursive macros in C, demystified (once the ugly crying stops)

#63

The c pre processor. C doesn't have macros. It's fucking miserable. Anyone who uses it is a masochist

It's a feature... macros allows people to change the language at will which is great when you're researching programming languages (like in lisp) but less good when you want maintainable and consistent code C++ has more powerful metaprogramming and look how that turned out

At least you can implement things like vector in C++. I challenge anyone to write the same for C macros. (this is semi-serious - if you get a full generic STL for C that is usable that would prevent a large number of bugs. The implementation can be as bad as you want, so long as the user API is not too difficult. Though note that I'm not a C programmer and so if there are better ways someone else is doing this I'm not aware of it)

Re: Recursive macros in C, demystified (once the ugly crying stops)

#64
I've ready the article 4 times already today and I'm still crying. This looks like the solution to a problem I'm having (C++, but I'm doing things that templates and constexpr can't do), but trying to get it all to work is painful. Kudos to the author at making an attempt to explain it.

Re: Recursive macros in C, demystified (once the ugly crying stops)

#65
post #56

Earlier quoted context omitted.

Thank you. I am actually perversely proud of it.

This was back in 80s when you were working on c compilers? That’s an interesting story (80s compiler scene and what you worked on) I’ve picked up bits and pieces over the years, have you written it up anywhere? Would be benefit for many I think.

https://github.com/DigitalMars/dmpp

It's Boost licensed. Open sourced.

No need for anyone else to struggle to implement a preprocessor.

Re: Recursive macros in C, demystified (once the ugly crying stops)

#66
The lack of (easy) recursion in CPP is so frustrating because it was always available in assembly languages with even very old and very simple macro assemblers- with the caveat that the recursion depth was often very limited, and no tail call elimination. For example, if you need to fill memory:

    ; Fill memory with backward sequence
    macro fill n
        word n
        if n != 0
            fill n - 1
        endif
    endm

    So "fill 3" expands to:
        word 3
        word 2
        word 1
        word 0
There is no way this was not known about when C was created. They must have been burned by recursive macro abuse and banned it (perhaps from m4 experience as others have said).

The other assembly language feature that I missed is the ability to switch sections. This is useful for building tables in a distributed fashion. Luckily you can do it with gcc.

Re: Recursive macros in C, demystified (once the ugly crying stops)

#67
post #50

Earlier quoted context omitted.

They could have just asked me :-)

They were deliberately leaving their C compiler broken because they considered C++ to be the replacement for C.

C++ uses an identical preprocessor.

Re: Recursive macros in C, demystified (once the ugly crying stops)

#68
post #64

I've ready the article 4 times already today and I'm still crying. This looks like the solution to a problem I'm having (C++, but I'm doing things that templates and constexpr can't do), but trying to get it all to work is painful. Kudos to the author at making an attempt to explain it.

If you can give me specifics on how it's not clear, I'd very much want to improve it. Please DM me about it.

Re: Recursive macros in C, demystified (once the ugly crying stops)

#69
post #68
post #64

I've ready the article 4 times already today and I'm still crying. This looks like the solution to a problem I'm having (C++, but I'm doing things that templates and constexpr can't do), but trying to get it all to work is painful. Kudos to the author at making an attempt to explain it.

If you can give me specifics on how it's not clear, I'd very much want to improve it. Please DM me about it.

Not so much that you are not clear - this is an area that is weird enough that I don't think it is possible to be clear, but you gave me some useful hints. I got some of what I want working.

Edit, I started writing and then realized that I need this to work on old gcc that doesn't support these tricks so I have to give up. (I can't wait until this old embedded hardware dies)

What I'm trying to do is #define(A, B) static int A ## _ ## B = register(MKSTRING(A ## _ ## B) take any number of arguments. I can get the register working, but my attempts are creating the variable name fail.

Re: Recursive macros in C, demystified (once the ugly crying stops)

#70
post #63

Earlier quoted context omitted.

It's a feature... macros allows people to change the language at will which is great when you're researching programming languages (like in lisp) but less good when you want maintainable and consistent code C++ has more powerful metaprogramming and look how that turned out

At least you can implement things like vector in C++. I challenge anyone to write the same for C macros. (this is semi-serious - if you get a full generic STL for C that is usable that would prevent a large number of bugs. The implementation can be as bad as you want, so long as the user API is not too difficult. Though note that I'm not a C programmer and so if there are better ways someone else is doing this I'm no…

I wonder how you like my vector: https://godbolt.org/z/97YGrbP9s (note, experimental library, but I see no fundamental issue).
Post reply on HN