151–160 of 192 posts
Reminds me of Arthur Whitney's k.h[1] Example: // remove more clutter #define O printf #define R return #define Z static #define P(x,y) {if(x)R(y);} #define U(x) P(!(x),0) #define SW switch #define CS(n,x) case n:x;break; #define CD default 1 - https://github.com/KxSystems/kdb/blob/master/c/c/k.h
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd...
I've been a C programmer for several years now (out of necessity - C is still the best language for firmware and embedded development) There's been a lot of noise on the internet about Rust and C++20 and "modern" languages. I recently had an opportunity to try some of these first hand. Honestly the new language features are all terrible with few exceptions. In general, anything that was added to a language to support…
In particular: "remove some of the undefined behaviors" I think the confusion caused by this is not nearly worth the optimization gained.
Compiler folks will say "but look, this loop is 58% faster!" but ignore the fact that slow code can be optimized through other means, including profiling, restructuring, etc.
Earlier quoted context omitted.
puts and printf aren't keywords, they're regular functions.
Well, sort of. Specifically, printf is an oddball function because it uses the varargs mechanism, and the whole format strings mechanism is inherently risky because it effectively bypasses the type system and says "trust me." Back when I was learning C, on a Mac with THINK C, misusing printf was a sure-fire way to crash the computer very quickly, especially since misaligned accesses of 16-bit or 32-bit words caused c…
I guess this article is to be taken lightly as kind of a "joke" ? The first proposed macro displayln is the archetype of malpractice. What if I want to do: if(some_condition) displayln("enjoy debugging that"); etc etc... almost all proposed changes seem to be awful ?
I've been a C programmer for several years now (out of necessity - C is still the best language for firmware and embedded development) There's been a lot of noise on the internet about Rust and C++20 and "modern" languages. I recently had an opportunity to try some of these first hand. Honestly the new language features are all terrible with few exceptions. In general, anything that was added to a language to support…
Great post. In particular: "remove some of the undefined behaviors" I think the confusion caused by this is not nearly worth the optimization gained. Compiler folks will say "but look, this loop is 58% faster!" but ignore the fact that slow code can be optimized through other means, including profiling, restructuring, etc.
This is more of knowing your language and tools. UB isn't some magic beast either, it's where it isn't really feasible for a language that runs on many platforms to dictate what happens. What should the std's say when you shift a signed int too far? Often the HW will have a way of doing it and others will not, so either don't do that or know your implementation
Those defines remind me of how Bourne shell was originally written using such a system to make the source look more like Algol 68. It might even still be maintained that way in BSD to this day [0]. [0] https://books.google.ca/books?id=9f9uAQAAQBAJ&pg=PA9&lpg=PA9...
Earlier quoted context omitted.
#define TYPE typedef #define STRUCT TYPE struct #define UNION TYPE union Well, that's extremely opinionated. Which I guess is the point. It does seem to add a BASIC-ness to the code. However, when I see landmines like these: #define TRUE (-1) #define FALSE 0 I might just hide instead of touching it.
Uh... This is serious landmine... I suggest author to change this.
This is amazing. Are there any larger examples that uses more of the functionality of the library that I could read?
Whilst it uses an older version of CNoEvil, and I haven't updated it yet, the largest application is probably evilshell [0]. There's also all the examples [1]. [0] https://git.sr.ht/~shakna/evilshell [1] https://git.sr.ht/~shakna/cnoevil3/tree/master/examples
<3
Earlier quoted context omitted.
Can you explain why?
To emphasise: This is about Bournegol. Nothing to do with this post. > Can you explain why? Because it isn't how most C libraries expect true/false to be defined. stdbool in C99 standardized things a bit, but before then what was generally accepted was: > true is 1 > false is !true (Often 0 in practice). Which means that any trivial: if(true) { ... } Won't work under Bournegol. Instead you _need_ to compare when doin…
Off topic, but in today's bitter and divided world, it's reassuringly wholesome that people can still get together to recite the alphabet in GitHub comments.