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

Cello – High Level C

libcello.org

Post reply on HN
Print view View original

61–70 of 83 posts

Re: Cello – High Level C

#61

Post by [deleted] »

asveikau wrote: post #40
shakna wrote: post #35

Earlier quoted context omitted.

> Not only that, but last I looked into this library's code there was a lot of undefined behavior Neither GCC's nor Clang's sanitisers pick up any undefined behaviour - and it's been like that for at least the last few years I've looked at it. As to ignoring errors, and ignoring alignment, I don't think I've ever seen anything like that in the project. I have seen several pull requests delayed so that they will. Over…

#define alloc_stack(T) ((struct T*)header_init( \ (char[sizeof(struct Header) + sizeof(struct T)]){0}, T, AllocStack)) You can't take char[sizeof(foo)] on the stack and cast it to a foo*. malloc implementations for example are cafeul to align the buffer they give you. Windows, for example, aligns on 8 bytes. Probably popular alloca implementations do this too. For example, googling for "alloca alignment" finds some d…

[deleted]

Re: Cello – High Level C

#62

Post by GolDDranks »

throwaway17_17 wrote: post #38
zozbot234 wrote: post #10

Earlier quoted context omitted.

> Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. True, but that's why we've got Rust these days. (Rust is actually more optimized than C, e.g. it will automatically reshuffle your structs to get rid of excess padding, and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints, thus equalizing perf…

How is Rust an answer to not liking C++‘a complexity. With the complexities inherent in the borrow semantics (with the box ref cell stuff that comes with it) and the complexities inherent in the type system and trait system, Rudy seems to be at least as complex as C++. In fact this point gets tossed out a lot, Rust is not a C replacement for C developers, it is at best a C++ replacement for developers who want someth…

But note what those complexities buy you: they bring restrictions and limitations that allow you reason _more_ about the code.

This is in stark contrast to some other complex features that allow more stuff to happen with less code.

Rust is indeed, complex in the sense that it's features are non-trivial, but I find it less complex than C++ in the sense that it has 1) less surface syntax (because of lack of historical baggage) 2) more cohesive, principled feature set (again, hindsight is 20/20) 3) it's inherently more limiting, which helps reading, understanding and reasoning about code.

Re: Cello – High Level C

#63

Post by kungtotte »

flukus wrote: post #34
aerovistae wrote: post #3

Seen this posted here years ago. Now as then, my gut feeling is that anyone doing serious work in C would never use something like this-- I feel like the fine grained low level control is exactly the reason they chose C in the first place, and they're not looking to escape from it or they would just choose a different language.

> I feel like the fine grained low level control is exactly the reason they chose C in the first place That's not the only reason, there is also simplicity, static typing and performance. If you favor the later two for whatever reason it can be used in places where you'd normal write a python/shell script or small program without too much extra effort (see https://github.com/RhysU/c99sh or suckless tools). Complexity…

You could also just pick something like Nim (https://nim-lang.org) if you wanted to hit the intersection of low effort, script-style programming with the addition of types and performance.

Re: Cello – High Level C

#64

Post by flukus »

da_chicken wrote: post #47
flukus wrote: post #34

Earlier quoted context omitted.

> I feel like the fine grained low level control is exactly the reason they chose C in the first place That's not the only reason, there is also simplicity, static typing and performance. If you favor the later two for whatever reason it can be used in places where you'd normal write a python/shell script or small program without too much extra effort (see https://github.com/RhysU/c99sh or suckless tools). Complexity…

> That's not the only reason, there is also simplicity, static typing and performance. I think the only meaningful benefit here is performance. Simplicity is at best determined by the nature of the problem and at worst a completely subjective opinion for C. Similarly, static typing is not usually something the programmer should care about that much. You need to know which paradigm your language uses, of course, but b…

Yes it's somewhat subjective, but other languages for the use case usually contain a lot more abstractions. They're more complex languages but they might enable less complex solutions to the problem at hand.

> IMX, you're more concerned with type safety, and C is not fully type safe like, say, Java is.

I'm concerned with finding errors, preferably at compile time. There have been very few times being fully type safe runtime like the jvm have done much for me compared to the java compiler. If I wanted more down that road then rust or ada would probably be better.

Re: Cello – High Level C

#65

Post by DonaldFisk »

rs23296008n1 wrote: post #59

Didn't C++ start out as a set of hacks on C? Fairly sure it was originally a preprocess stage ahead of an ordinary c compiler. Raises the question of how usefully far you can make C twist using macros / preprocessor. Candidates like Forth or Lisp seem possible. A few weekends at most. Might need to take a few liberties. Python... Perhaps if you implement a less dynamic subset? Duck typing may trip you up. To what ext…

I wrote my own Lisp. The virtual machine, which is a stack machine, is written in C. The interpreter, which runs until the system compiles itself, is written in C, but makes heavy use of C macros. The rest of the code, including the compiler, is in Lisp.

Code in the interpreter is directly converted to byte code, e.g. the macro Car generates the virtual machine instruction Car, rather than executing the code for car. The alternative would have been to generate byte code by hand, would have been error-prone. Here's the code for cons and let:

    Define("cons", 2)
      Local1 Local2 Cons Ret
    Termin

    DefineF("let")
      Local1 Car
      Local2 /* initialize new env */
      Prog(1)
      Ret

      Params(2)
      Until Local1 Null Do
        Local1 Caar /* var */
        Local1 Cadar Free12 Call("eval") /* val in old env */
        Local2 /* env */
        ACons
        SetLocal2 Pop /* update new env */
        PopLocal1
      Od
      Free11 Cdr Local2 Call("progn") /* use new env */
      Ret
    Termin
It is actually C, with heavy use of macros. But it can be read as Reverse Polish Lisp. It can also be thought of as a Lispy Forth.

Re: Cello – High Level C

#66

Post by tluyben2 »

kungtotte wrote: post #63
flukus wrote: post #34

Earlier quoted context omitted.

> I feel like the fine grained low level control is exactly the reason they chose C in the first place That's not the only reason, there is also simplicity, static typing and performance. If you favor the later two for whatever reason it can be used in places where you'd normal write a python/shell script or small program without too much extra effort (see https://github.com/RhysU/c99sh or suckless tools). Complexity…

You could also just pick something like Nim ( https://nim-lang.org ) if you wanted to hit the intersection of low effort, script-style programming with the addition of types and performance.

Did Nim compile times improve? I wrote a production project in it which was about 50k loc and I spent most time waiting for compilation.

Re: Cello – High Level C

#67

Post by carlmr »

rs23296008n1 wrote: post #59

Didn't C++ start out as a set of hacks on C? Fairly sure it was originally a preprocess stage ahead of an ordinary c compiler. Raises the question of how usefully far you can make C twist using macros / preprocessor. Candidates like Forth or Lisp seem possible. A few weekends at most. Might need to take a few liberties. Python... Perhaps if you implement a less dynamic subset? Duck typing may trip you up. To what ext…

Nim transpiles to C. It's very cool since there are C compilers for almost every processor.

Re: Cello – High Level C

#68

Post by z92 »

kazinator wrote: post #51

The strategy in the GC for determining the stack top for hunting GC roots will not work on all architectures. On aaarch-64, the address of a local dummy variable may be above a register save area in the stack frame, and thus the scan will miss some GC roots. In TXR Lisp, I used to use a hacked constant on aarch64: STACK_TOP_EXTRA_WORDS. It wasn't large enough to straddle the area, and so operation on aarch64 was unre…

I use argv[0] as stack head.

Re: Cello – High Level C

#69

Post by dgellow »

oddity wrote: post #15
zozbot234 wrote: post #10

Earlier quoted context omitted.

> Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. True, but that's why we've got Rust these days. (Rust is actually more optimized than C, e.g. it will automatically reshuffle your structs to get rid of excess padding, and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints, thus equalizing perf…

Rust is a compelling alternative to C++ for large scale systems software (browsers, video games, etc) but, as of the last time I checked (~2 months ago) it doesn’t scale down as well as C does, or to as many platforms as C does. A lot of this is that C has an unfair advantage from being well established, but an advantage is an advantage .

> Rust is a compelling alternative to C++ for [...] video games

I think it is unlikely to see rust gain much traction in the game dev world. Everything is currently done in C++, and there is low incentives to move to something "safer" or "more secure", because that's not seen as relevant properties by game developers.

What matters for game dev is mostly (not listed in a specific order):

- raw performances

- low latency

- as low as an overhead as possible when dealing with GPUs

- control over memory management

In that context the borrow checker can be an unnecessary constraint, and the safety concern isn't really something that relevant. In the other hand, the rust package manager is really something that is missing in the C++ world, and would be awesome to have for game devs.

Re: Cello – High Level C

#70

Post by kungtotte »

tluyben2 wrote: post #66
kungtotte wrote: post #63

Earlier quoted context omitted.

You could also just pick something like Nim ( https://nim-lang.org ) if you wanted to hit the intersection of low effort, script-style programming with the addition of types and performance.

Did Nim compile times improve? I wrote a production project in it which was about 50k loc and I spent most time waiting for compilation.

I just checked out and built the Nim compiler + stdlib itself.

real: 161.26s (including the GCC bootstrap stage).

cloc reports 253500 lines of Nim in the project.

This was on a Ryzen 7 3700x @ 3.6GHz.

Re-running it immediately after (does not build the GCC bootstrap stage)

real 22.55s

Post reply on HN