Let's Destroy C • Hacker News Board

Re: Let's Destroy C

#81

Post by 32gbsd » Thu, Jan 30, 2020, 12:05 PM UTC

I hope we get some new stuff out of this. The world is lacking in new stuff because everyone is in the business of creating slavery apis.

Re: Let's Destroy C

#82

Post by notacoward » Thu, Jan 30, 2020, 12:13 PM UTC

nothrabannosir wrote: post #39

Big fan. I don’t see support for exceptions, maybe this can help: https://github.com/hraban/c-exceptions (I ended up using this in a job once. They didn’t hire me back...)

Agreed, exceptions would fit right in with all the other "people think they're great but they're really terrible" ideas in the OP.

Re: Let's Destroy C

#83

Post by wbl » Thu, Jan 30, 2020, 12:27 PM UTC

shakna wrote: post #18

thrwaway69 wrote: post #15

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…

Any nonzero integer is considered true in that expression, so if(TRUE) still works.

Re: Let's Destroy C

#84

Post by non-entity » Thu, Jan 30, 2020, 12:40 PM UTC

0xdead wrote: post #36

Perfect usage of the title to get on HN frontpage.

I really expected this to be another aggressive Rust marketing peice at first

Re: Let's Destroy C

#85

Post by gpderetta » Thu, Jan 30, 2020, 12:43 PM UTC

shakna wrote: post #35

artsr wrote: post #32

When I started learning C++, there was't a C++ compiler available for my Atari ST (late 80s), there was only Borland C. So instead I used the C preprocessor to emulate classes, virtual functions etcetera. Not everything could be implemented this way, but it looked like C++ close enough for me to learn it.

That's basically how C++ was originally created, or the prototype, "C with Classes", albeit with a custom preprocessor. [0] > In October of 1979 I had a pre− processor, called Cpre, that added Simula− like classes to C run-ning and in March of 1980 this pre− processor had been refined to the point where it supported onereal project and several experiments. Recognising that you could do it that way is kinda awesome. M…

Thanks, awesome paper (which remind me that I should read the ARM at some point).

Interesting stuff:

"Cfront [the fist c++ compiler] was (and is) a traditional compiler front− end performing a complete check of the syntax and semantics of the language"

"[...] the C compiler is used as a code generator only. [...]. I stress this because there has been a long history of confusion about what Cfront was/is. It has been called a preprocessor because it generates C, and for people in the C community (and elsewhere) that has been taken as proof that Cfront was a rather simple program – something like a macro preprocessor."

Cfront being a preprocessor is something that gets repeated often. As you correctly point out, cpre was the preprocessor and it wasn't realy C++ yet.

Re: Let's Destroy C

#86

Post by userbinator » Thu, Jan 30, 2020, 12:48 PM UTC

gpderetta wrote: post #85

shakna wrote: post #35

Earlier quoted context omitted.

That's basically how C++ was originally created, or the prototype, "C with Classes", albeit with a custom preprocessor. [0] > In October of 1979 I had a pre− processor, called Cpre, that added Simula− like classes to C run-ning and in March of 1980 this pre− processor had been refined to the point where it supported onereal project and several experiments. Recognising that you could do it that way is kinda awesome. M…

Thanks, awesome paper (which remind me that I should read the ARM at some point). Interesting stuff: "Cfront [the fist c++ compiler] was (and is) a traditional compiler front− end performing a complete check of the syntax and semantics of the language" "[...] the C compiler is used as a code generator only. [...]. I stress this because there has been a long history of confusion about what Cfront was/is. It has been c…

I believe the "modern" term for Cfront would be "transpiler".

Re: Let's Destroy C

#87

Post by davidhyde » Thu, Jan 30, 2020, 1:07 PM UTC

This reminds me of Arduino.

evil.h == arduino.h

Re: Let's Destroy C

#88

Post by garaetjjte » Thu, Jan 30, 2020, 1:14 PM UTC

    // Original macro hack by Robert Elder (c) 2016

Described also back in 2000 on https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

Re: Let's Destroy C

#89

Post by macintux » Thu, Jan 30, 2020, 1:17 PM UTC

I haven't looked closely at either, but the spirit of this effort reminds me of Cello, recently discussed here: https://news.ycombinator.com/item?id=22102533

Re: Let's Destroy C

#90

Post by bjornjajajaja » Thu, Jan 30, 2020, 1:27 PM UTC

C has its place; every language has its quirks. I think a lot of emphasis needs to be put on testing code. Like SQLite uses Tcl to script tests. C is easy to test because the “software units” are only structures and functions.