Let's Destroy C

#1

Post by shakna » Thu, Jan 30, 2020, 3:52 AM UTC

Let's Destroy C
gist.github.com

Re: Let's Destroy C

#2

Post by awalias » Thu, Jan 30, 2020, 4:28 AM UTC

the best thing about this was discovering https://git.sr.ht/

Re: Let's Destroy C

#3

Post by shakna » Thu, Jan 30, 2020, 5:02 AM UTC

awalias wrote: post #2

the best thing about this was discovering https://git.sr.ht/

The extremely flexible todo, and build parts of the site are probably my favourites.

Anonymous non-user people allowed on issue tracker that doesn't have to be linked to any repo? Awesome. (And you can export easily.)

Easy to combine multiple build projects into a single build that can be kicked off by any one of the projects? Sweet.

Drew is also really responsive if you run into any problems.

Re: Let's Destroy C

#4

Post by yjftsjthsd-h » Thu, Jan 30, 2020, 6:13 AM UTC

shakna wrote: post #3

awalias wrote: post #2

the best thing about this was discovering https://git.sr.ht/

The extremely flexible todo, and build parts of the site are probably my favourites. Anonymous non-user people allowed on issue tracker that doesn't have to be linked to any repo? Awesome. (And you can export easily.) Easy to combine multiple build projects into a single build that can be kicked off by any one of the projects? Sweet. Drew is also really responsive if you run into any problems.

Part of what makes sr.ht great is that it's made of tools that can be used together or separately. If you want to use it for just task tracking, great. If you want to use it for task tracking, git repo, and CI/CD, that's fine. If you want to use it for task tracking on a project that keeps code on github and does CI on gitlab... It still works great:)

Re: Let's Destroy C

#5

Post by roywiggins » Thu, Jan 30, 2020, 6:17 AM UTC

Ah, finally a modern successor to Bournegol: http://oldhome.schmorp.de/marc/bournegol.html

Re: Let's Destroy C

#6

Post by cperciva » Thu, Jan 30, 2020, 6:18 AM UTC

While I'm not a fan of the specific changes shown in this article, I do agree with the principle of "remove boilerplate when possible". I found that the largest amount of boilerplate I ever wrote was in main() to parse the command line, and to that end I wrote a "magic getopt", which handles both short and long options in-line without external tables (https://www.daemonology.net/blog/2015-12-06-magic-getopt.htm... ); and PARSENUM, which handles the common cases of parsing human-readable values while appropriately checking for overflow (https://github.com/Tarsnap/libcperciva/blob/master/util/pars...).

Re: Let's Destroy C

#7

Post by kazinator » Thu, Jan 30, 2020, 6:24 AM UTC

> Windows has a different line ending

But not when printing to stdio.h text streams; \n turns into the right line ending.

Re: Let's Destroy C

#8

Post by shakna » Thu, Jan 30, 2020, 6:25 AM UTC

roywiggins wrote: post #5

Ah, finally a modern successor to Bournegol: http://oldhome.schmorp.de/marc/bournegol.html

    #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.

Re: Let's Destroy C

#9

Post by chrisbrandow » Thu, Jan 30, 2020, 6:30 AM UTC

Reminds me a lot of how the first version of objective-C was implemented

Re: Let's Destroy C

#10

Post by kccqzy » Thu, Jan 30, 2020, 6:33 AM UTC

GNU lambdas are incredibly evil. In order for lambdas to capture their environment and yet still be available as a function pointer, the compiler makes the stack executable and stores the trampoline code on the stack.

C++ lambdas don't suffer from this problem.