Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Preprocessor Hell

jacquesmattheij.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: C Preprocessor Hell

#21

Post by anon_d »

angersock wrote: post #18
anon_d wrote: post #9

Earlier quoted context omitted.

Yep. Why try to force a tool into a role it was never designed for? You use m4 or just write a preprocessor in any language. If you really want to do complicated lisp-style meta-programming stuff with C, just write another C program to pre-process your C program. It's more work, but it gives you complete control over the syntax.

...or just use Python, Ruby, or Lisp directly? Doing weird things to a C file (while occasionally useful) is just increasing the technical debt of your teammates later. (though, we do have a closure-ish macro in our codebase that's pretty nifty, so do as I say not as I do etc.)

    >> If you really want to do complicated lisp-style meta-programming stuff
    > Increases technical debt
    Yep. The sane solution is to just not do stuff like this at all. In rare
    situations it ends up being worth it.

Re: C Preprocessor Hell

#22

Post by cobrausn »

bunderbunder wrote: post #19
groovy2shoes wrote: post #17

Earlier quoted context omitted.

The ability to commit segment violations is a consequence of the broader abilities you get with pointers as a language feature. In many cases, neither of those things are desirable, but there are cases (e.g., systems programming) where they are very desirable.

Sure, but LISP was never intended as a systems or embedded programming language. Criticizing LISP for not being good at doing low-level tasks is akin to criticizing Harley-Davidson's motorcycles because they don't float.

Or akin to criticizing C for not being an expressive, high-level language.

Also, in response to your first point: http://en.wikipedia.org/wiki/Lisp_machine

Re: C Preprocessor Hell

#23

Post by agumonkey »

BudVVeezer wrote: post #16
bunderbunder wrote: post #14

Earlier quoted context omitted.

There are some who would suggest that allowing you to commit segment violations is not generally a desirable language feature.

Except when 0xDEADBEEF happens to be the memory address overlaying the custom hardware registers, and setting it to 0x42 turns the blinky light on. There are some cases where manipulating static memory locations is not only a good thing, but the only way to do something (at least for embedded programming). Not saying that your point is invalid, btw.

wild guess:

  (overlay 'light #on)
overlay being a macro to access a predefined ffi setup.

Re: C Preprocessor Hell

#24

Post by wglb »

ctdonath wrote: post #7

"Lisp programmers should stop reading right now because they'll likely suffer severe injury of the jaw muscles as they laugh themselves silly at how hard it is to do some things in C." Naive question: in Lisp, how would you set the byte at address 0xDEADBEEF to 0x42?

Define a C type and use FFI to set the value in memory.

Quite easy.

Re: C Preprocessor Hell

#25

Post by cube13 »

Why not just make an internal API function? In my experience with high performance, multiplatform C, macro usage is usually the last thing we do. Macros are absolutely horrendous to debug, and tends to lead to less readable code. They're useful to alias specific platform implementations to a standard interface, or for tiny functions that absolutely need to be inlined for performance.

In this specific case, it might make more sense to have the programmer tell you how many arguments to expect and work with it that way, rather than going through this chain of macros. C doesn't allow function arguments to change dynamically, so that might be a slightly better approach. It would be easier to understand, but a bit harder to maintain code that uses it.

Re: C Preprocessor Hell

#26

Post by jacquesm »

drblast wrote: post #6

I don't know why people don't seem to think of this when confronted with the limitations of the standard C preprocessor, but Perl or Lisp both make excellent C preprocessors. You aren't required to only use the C source code transformation tools that a default install of GCC provides.

For valid reasons the build system is very minimal and the number of external dependencies is limited to 'absolutely necessary', adding another interpreter to the list of dependencies is simply not an option.

But sure, if that's not one of the limitations you're working under then code generation through another language is definitely a possibility.

Re: C Preprocessor Hell

#27

Post by cube13 »

drblast wrote: post #6

I don't know why people don't seem to think of this when confronted with the limitations of the standard C preprocessor, but Perl or Lisp both make excellent C preprocessors. You aren't required to only use the C source code transformation tools that a default install of GCC provides.

Because it moves you to a whole new circle of hell from the very common C preprocessor one that every C developer on the planet has been in at one point or another.

If you're using VS, you're going to want to use the included pre-build steps in the vcproj to generate the source. Unfortunately, you can't just edit the source in place, unless your team is absolutely in love with your SCS' rollback capability. So that means that in order to edit the code, you need to open it up in either another project, or open it outside the IDE's solution environment.

It also removes the ability to do partial rebuilds, since every file will be necessarily touched by the preprocessing script before compiling, so it's a "new" file as far as the IDE is concerned.

Debugging becomes a chore, because the code in source control is not the code that was compiled, breaking line counts and breakpoints.

Finally, it's a deployment nightmare for your build staff, since they need to make sure that everyone is standardized on the same perl version, maintain the scripts in addition to the makefiles, and make sure that everyone's dev environment works with it.

Re: C Preprocessor Hell

#28

Post by nickik »

cobrausn wrote: post #22
bunderbunder wrote: post #19

Earlier quoted context omitted.

Sure, but LISP was never intended as a systems or embedded programming language. Criticizing LISP for not being good at doing low-level tasks is akin to criticizing Harley-Davidson's motorcycles because they don't float.

Or akin to criticizing C for not being an expressive, high-level language. Also, in response to your first point: http://en.wikipedia.org/wiki/Lisp_machine

If C would have lisp syntax it could do the alot of the same abstractions.

Re: C Preprocessor Hell

#29

Post by bunderbunder »

nickik wrote: post #28
cobrausn wrote: post #22

Earlier quoted context omitted.

Or akin to criticizing C for not being an expressive, high-level language. Also, in response to your first point: http://en.wikipedia.org/wiki/Lisp_machine

If C would have lisp syntax it could do the alot of the same abstractions.

A low-level imperative language with s-expression syntax would be one heck of an esoteric language.

Re: C Preprocessor Hell

#30

Post by Loke »

ctdonath wrote: post #7

"Lisp programmers should stop reading right now because they'll likely suffer severe injury of the jaw muscles as they laugh themselves silly at how hard it is to do some things in C." Naive question: in Lisp, how would you set the byte at address 0xDEADBEEF to 0x42?

It's very simple:

(setf (cffi:mem-ref (cffi:make-pointer #xDEADBEEF) :int) #x42)

Post reply on HN