A “Better C” Benchmark
zserge.com
A “Better C” Benchmark
1–10 of 192 posts
Re: A “Better C” Benchmark
#2[deleted]
Re: A “Better C” Benchmark
#3What I find funny is his choice of languages: 'hipe driven' I'd say.
If you can use a GCd language like Go why would you go with Rust(which add a lot of complexity) or Zig(which is unsafe(1)) instead of the numerous existing GCd languages D,Nim, Crystal, Java,... which provides memory safety without complexity
If you can't why evaluate Go instead of Ada or DasBetterC?
1: At work a frequent issue in C++ is UAF a pointer to a stack variable which outlives the function, Zig don't help you here..
Re: A “Better C” Benchmark
#4Simplicity wins. Always.
Re: A “Better C” Benchmark
#5What I find funny is his choice of languages: 'hipe driven' I'd say. If you can use a GCd language like Go why would you go with Rust(which add a lot of complexity) or Zig(which is unsafe(1)) instead of the numerous existing GCd languages D,Nim, Crystal, Java,... which provides memory safety without complexity If you can't why evaluate Go instead of Ada or DasBetterC? 1: At work a frequent issue in C++ is UAF a point…
> 1: At work a frequent issue in C++ is UAF a pointer to a stack variable which outlives the function, Zig don't help you here..
Sorry but if this sort of UAF is actually frequent, I would hazard a guess that your coworkers would struggle in pretty much any language? RAII-based lifetime management really isn't that difficult, and the type of bug you are referring to isn't even subtle.
Re: A “Better C” Benchmark
#6What I find funny is his choice of languages: 'hipe driven' I'd say. If you can use a GCd language like Go why would you go with Rust(which add a lot of complexity) or Zig(which is unsafe(1)) instead of the numerous existing GCd languages D,Nim, Crystal, Java,... which provides memory safety without complexity If you can't why evaluate Go instead of Ada or DasBetterC? 1: At work a frequent issue in C++ is UAF a point…
> 1: At work a frequent issue in C++ is UAF a pointer to a stack variable which outlives the function, Zig don't help you here.. Sorry but if this sort of UAF is actually frequent, I would hazard a guess that your coworkers would struggle in pretty much any language? RAII-based lifetime management really isn't that difficult, and the type of bug you are referring to isn't even subtle.
I dunno what you’re saying; this kind of bug also proves difficult to avoid in large, security-critical projects like web browser engines.
Re: A “Better C” Benchmark
#7Earlier quoted context omitted.
> 1: At work a frequent issue in C++ is UAF a pointer to a stack variable which outlives the function, Zig don't help you here.. Sorry but if this sort of UAF is actually frequent, I would hazard a guess that your coworkers would struggle in pretty much any language? RAII-based lifetime management really isn't that difficult, and the type of bug you are referring to isn't even subtle.
I dunno what you’re saying; this kind of bug also proves difficult to avoid in large, security-critical projects like web browser engines.
D is very good at detecting dangling pointers into the stack at compile time.
Re: A “Better C” Benchmark
#8What I find funny is his choice of languages: 'hipe driven' I'd say. If you can use a GCd language like Go why would you go with Rust(which add a lot of complexity) or Zig(which is unsafe(1)) instead of the numerous existing GCd languages D,Nim, Crystal, Java,... which provides memory safety without complexity If you can't why evaluate Go instead of Ada or DasBetterC? 1: At work a frequent issue in C++ is UAF a point…
Had to look it up, DasBetterC is not german, it's "D as a better C"
Re: A “Better C” Benchmark
#9Simplicity wins. Always.
Yes, the trouble is agreeing on a definition of "simple"
Re: A “Better C” Benchmark
#10I threw together a D Programming language glob-grep based off of the Zig version the author posted, if anyone is curious: https://gist.github.com/aruthane/005c6c48f0deb9c4bfc83bc75e0...