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

171–180 of 192 posts

Re: A “Better C” Benchmark

#171

Post by CyberDildonics »

renox wrote: post #167
CyberDildonics wrote: post #108

Earlier quoted context omitted.

I agree and don't understand why this would be controversial. There are plenty of aspects of programming that need systematic solutions instead of just telling people to get better, but returning pointers to the stack should not be high on that list. If people are doing that, it means they don't understand what they are doing or aren't thinking about what they are writing, probably both. It is much easier to return r…

It doesn’t happen very often but each time there was a new developer on the team they made such mistake, that’s a way to teach them about valgrind (what a wonderful software!) I guess. We work in a ‘low latency’ domain where heap allocation is avoided, this may explain that it happens more often to us.

Why would avoiding heap allocation explain it? Why is anyone getting the address of a stack allocated variable in the first place since it already in scope? What are people returning pointers from functions at all?

Re: A “Better C” Benchmark

#172

Post by CyberDildonics »

usrnm wrote: post #169
CyberDildonics wrote: post #112

Earlier quoted context omitted.

Are you actually using new and delete outside your own data structures? I have barely used new or delete for years, I don't even use them when building data structures - the vast majority of the time I make compound data structures out of what is in the standard library. It is only when memory layout needs to be very specific that I use new and even then it is placement new.

You don't need to use delete explicitly to control the lifetime of objects in C++. A properly placed "}" or a call to something like .release() can be just as effective. The problem is, there is simply no way to do it in a GC language.

I think you completely misunderstood what I wrote. I was asking the person I replied to why they needed to use new and delete.

Re: A “Better C” Benchmark

#173

Post by shepmaster »

galangalalgol wrote: post #162
shepmaster wrote: post #67

Earlier quoted context omitted.

A list of dependencies: https://doc.rust-lang.org/cargo/commands/cargo-tree.html Download all dependencies locally: https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

I think maybe I don't understand vendor. I thought you had to have your project on the internet facing machine to vendor its dependencies. Which I cannot do.

Likewise, I don’t understand the disconnect. You have to have your list of dependencies on an internet connected machine, yes, but you already allowed that. You said:

> I could then go to an internet facing machine and run a cargo command

Copy over your Cargo.toml to that machine, run vendor, copy the vendor files back.

Re: A “Better C” Benchmark

#174

Post by Too »

lew89 wrote: post #73
carols10cents wrote: post #70

Earlier quoted context omitted.

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

Such an error is nobrainer? Yet you deployed your code with several of them?

Understandably you didn’t put your whole effort into a small code example in a HN comment, but a language that allows one to do so without any errors would be big productivity and safety gain.

Re: A “Better C” Benchmark

#175

Post by Too »

renox wrote: post #66
yakubin wrote: post #59

Earlier quoted context omitted.

> His dismissal of C++ as "not having a build system" seems like considering the language without the ecosystem. Using cmake and llvm solves all of his gripes on C++. Last week I debugged an issue in a big C++ codebase, where we were getting memory corruption. Source of the issue? Compiler, linker and build system being separate things and only compiler understanding types (also, lack of modules, which is another sym…

Yep been there done that two months ago, took me two days (at least) to find the issue as a corruption which happen in -O3 but not in debug build which neither valgrind nor ASAN can find is pretty mysterious..

Unless you left out some details, this sounds more like plain UB and buggy c++ code manifesting itself with different symptoms depending on the O level.

This has not as much to do with the loosely coupled build system complexity you have to scaffold in a c++ project, more issues in the core language itself.

Re: A “Better C” Benchmark

#176

Post by m45t3r »

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 fact that they're not NULL terminated and the slices itself have length information is already a great improvement over C.

Re: A “Better C” Benchmark

#177

Post by lew89 »

Too wrote: post #174
lew89 wrote: post #73

Earlier quoted context omitted.

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

Such an error is nobrainer? Yet you deployed your code with several of them? Understandably you didn’t put your whole effort into a small code example in a HN comment, but a language that allows one to do so without any errors would be big productivity and safety gain.

Of course, in the program like this. It's quite obvious that for a bigger program it would be much harder. I wouldn't use C for a big monolith system or if I had to, I would put much effort in diagnostic features.

I don't write professionaly C code. I use it for my purposes so debugging is easy. I agree that such a problem in a bigger system whithout ability to reproduce environment and debug would be very nasty. However that is matter of context. In bigger system it's more reasonable to buy more safety for price of simplicity, because I doubt any of competitors in the benchmark is as simple as C.

Re: A “Better C” Benchmark

#178

Post by carols10cents »

lew89 wrote: post #144
Ar-Curunir wrote: post #81

Earlier quoted context omitted.

Maybe it doesn’t matter for small programs, but probably in large programs tracing the control flow would be non trivial, so, as the parent said, over the lifetime of the program it would add up

Is there any language that can save you from control tracing problem? I think that well made architecture is only solution. In fact I would say that C is easier in that respect (if you don't use goto), because all control flow is explicit. In other languages you have exceptions, polymorphism, implicit constructors, destructors (and their order in case of inheritance, templates, etc. C is dead simple in that respect.…

It's not just a lack of experience-- Microsoft developers, Chrome developers, Mozilla developers, all have problems with memory management :) https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

Re: A “Better C” Benchmark

#179

Post by igouy »

silisili wrote: post #164
gher-shyu3i wrote: post #163

Earlier quoted context omitted.

Can you link to the bitbucket pull requests?

Which repo? If it has a full history, perhaps I could find it? I have a link, but it's dead now... http://benchmarksgame.alioth.debian.org/u32/program.php?test... This was in 2013. My first submission was using memory pools for binary trees. It was rejected for using memory pools, even though the C version quite literally used mempool. I even redid it to use a 'third party' mempool library, rejected for the same reas…

https://salsa.debian.org/benchmarksgame-team/archive-alioth-...

https://blog.golang.org/ismmkeynote

Re: A “Better C” Benchmark

#180

Post by galangalalgol »

shepmaster wrote: post #173
galangalalgol wrote: post #162

Earlier quoted context omitted.

I think maybe I don't understand vendor. I thought you had to have your project on the internet facing machine to vendor its dependencies. Which I cannot do.

Likewise, I don’t understand the disconnect. You have to have your list of dependencies on an internet connected machine, yes, but you already allowed that. You said: > I could then go to an internet facing machine and run a cargo command Copy over your Cargo.toml to that machine, run vendor, copy the vendor files back.

thanks!
Post reply on HN