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

A “Better C” Benchmark

zserge.com

Post reply on HN
Print view View original

71–80 of 192 posts

Re: A “Better C” Benchmark

#71

Post by scatters »

WalterBright wrote: post #37
renox wrote: post #29

Earlier quoted context omitted.

>I would hazard a guess that your coworkers would struggle in pretty much any language? Uh? This issue wouldn't happen in Java because everything is heap(GC) allocated. Which is probably why developers new to C++ have this issue. Walter Bright said below that the D compiler find most of these issue at compile time, well that's nice for D but unfortunately that isn't the case for C++ at least not for gcc9.

Doing what D does to detect references to expired stack frames would require some restructuring of C++'s semantics, which seems unlikely. For example, D can detect this error: @safe: int* f(int* p) { return p; } int* g() { int i; return f(&i); } Compile with: dmd test -dip1000 and the result: Error: reference to local variable i assigned to non-scope parameter p calling test.f

At -O2 or above, gcc emits Wreturn-local-addr.

Re: A “Better C” Benchmark

#72

Post by mhh__ »

mhh__ wrote: post #40
maccard wrote: post #38

I think there is definitely merit in these kinds of posts. This developers measure of productivity is "how low level can I go" clearly; they declared zig was clear despite saying this: > The lack of string handling routines in the stdlib was unexpected, to concatenate strings one has to do everything manually - allocate the buffer, put strings there. Or use formatter and an allocator to print both strings side by sid…

> using cake and LLVM Sure they (not sure about LLVM as a build system?) work but they really aren't all that great in my experience.

How did I not notice it corrected cmake to cake...

Re: A “Better C” Benchmark

#73

Post by lew89 »

carols10cents wrote: post #70
lew89 wrote: post #58

Earlier quoted context omitted.

There is missing NULL check, but it doesn't crash, because the function would get nonexistent filename only if filesystem driver would do something strange (or file would be deleted just between readdir and fopen). xD I also noticed, that I don't close files and directories. Not a big deal, because fully functional and 100% correct program wasn't the goal here. :) EDIT: Actually fopen would return NULL when file is n…

I like that I don't have to spend the time debugging trivial problems like these in Rust though. The compiler catches them for me, and I get more time and brain power to spend debugging nontrivial problems. It adds up.

Everything is matter of price. Such an error is nobrainer actually, because just before I get an error message. If I don't know that yet, I run on gdb and everything's clear. Couple of seconds. How manyof them I have to do to ballance learning a new language(and I'm not sure if I like it eventually)? If I was a system software developer, that would probably be a good choice. I program mostly in high level languages, so maybe not. :)

Re: A “Better C” Benchmark

#74

Post by flohofwoe »

maccard wrote: post #38

I think there is definitely merit in these kinds of posts. This developers measure of productivity is "how low level can I go" clearly; they declared zig was clear despite saying this: > The lack of string handling routines in the stdlib was unexpected, to concatenate strings one has to do everything manually - allocate the buffer, put strings there. Or use formatter and an allocator to print both strings side by sid…

> This combined with "strings" being byte buffers like in C are not a good thing.

The problem of C strings is that they are zero-terminated, not that they are byte buffers. Strings in Zig are foremost slice types (pointer/size pairs), but for C compatibility, Zig also has the concept of 'sentinel terminated arrays':

https://ziglang.org/documentation/master/#Sentinel-Terminate...

> how do you handle an umlaut in zig

Via UTF-8 encoding, as it should be.

> cmake...

I use cmake for my C and C++ stuff too because it's the defacto standard, but Rust's cargo or Zig's integrated build system are on a whole different level.

Re: A “Better C” Benchmark

#75

Post by gameswithgo »

renox wrote: post #3

What 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…

The whole point of his experiment was to learn about the ergonomics of these languages, to investigate the hype. If you did the experiment and say, found that Rust was super easy, then you could avoid GC and get some free efficiency. If you found that Rust was hard, then you know only to use it when you NEED the efficiency.

Re: A “Better C” Benchmark

#76

Post by gameswithgo »

bluecalm wrote: post #52
renox wrote: post #3

What 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…

GCed language style just seem so messy to me. I like manual memory management. It forces you to think about lifetimes and encourages better design. Does an object persist or is it temporary? Maybe it's a good idea to have well defined state. GC languages encourage lousy thinking and design. GC pauses are still a thing as well.

There are a lot of sweeping unsubstantiated assertions here, and unclearly defined ideas. What is lousy thinking and design? What are the practical downsides of it in the program? Given how many exploits are caused by memory mistakes in C and C++, maybe using those is actually the lousy thinking?

Re: A “Better C” Benchmark

#77

Post by maccard »

flohofwoe wrote: post #74
maccard wrote: post #38

I think there is definitely merit in these kinds of posts. This developers measure of productivity is "how low level can I go" clearly; they declared zig was clear despite saying this: > The lack of string handling routines in the stdlib was unexpected, to concatenate strings one has to do everything manually - allocate the buffer, put strings there. Or use formatter and an allocator to print both strings side by sid…

> This combined with "strings" being byte buffers like in C are not a good thing. The problem of C strings is that they are zero-terminated, not that they are byte buffers. Strings in Zig are foremost slice types (pointer/size pairs), but for C compatibility, Zig also has the concept of 'sentinel terminated arrays': https://ziglang.org/documentation/master/#Sentinel-Terminate... > how do you handle an umlaut in zig V…

> utf-8 as it should be

Agreed, but now your standard library doesn't have string support, it has byte buffer support. That's no improvement over C, compared to rust.

Re: A “Better C” Benchmark

#78

Post by maccard »

naavis wrote: post #57
linkdd wrote: post #44

Earlier quoted context omitted.

CMake, SCons, Autotools, Meson, Premake, to quote only them. They are build systems alright, but they miss the most crucial point: dependency managment. On the other side we have: - cargo for Rust - buck and buckaroo for C++ which seems nowhere near complete Am I missing something?

This is exactly my painpoint with C++ too. With Rust and such I'm one simple command line call away from installing a dependency. With C++ every dependency is a battle.

vcpkg install.

It integrates with cmake too!

Re: A “Better C” Benchmark

#79

Post by vitus »

A nit/bug re: the glob matching algorithm in use:

'?' evidently represents "any character" per the !glob("h?i", "hi") test.

But, if I add a test for glob("???", "hi"), that succeeds unexpectedly even though it should run out of input.

I believe it's because the '?' case checks nt (This looks like it's the case for all four languages, as the glob algorithm looks identical in all four, modulo syntax differences)

Re: A “Better C” Benchmark

#80

Post by flohofwoe »

maccard wrote: post #77
flohofwoe wrote: post #74

Earlier quoted context omitted.

> This combined with "strings" being byte buffers like in C are not a good thing. The problem of C strings is that they are zero-terminated, not that they are byte buffers. Strings in Zig are foremost slice types (pointer/size pairs), but for C compatibility, Zig also has the concept of 'sentinel terminated arrays': https://ziglang.org/documentation/master/#Sentinel-Terminate... > how do you handle an umlaut in zig V…

> utf-8 as it should be Agreed, but now your standard library doesn't have string support, it has byte buffer support. That's no improvement over C, compared to rust.

The downside of a single string type built into the standard library or even into the language is that it needs to be both flexible and performant, and in my experience, those two things exclude each other (e.g. how do you append two high-level strings like "str1 + str2" without hidden allocation?).

Apart from that, Zig's string processing functions are not that bad, what's unexpected is that they are in the memory-operations part of the standard library, not in a specific "string module" (after all, the Zig compiler is (being) written in Zig, and the parser needs to do a lot of string-munching, so I guess we'll get more powerful string processing helper functions in the standard library over time).

But if I need to do lots of high-level string processing I probably wouldn't chose a systems programming language to begin with, languages like Python are a better match for this.

Post reply on HN