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

The case against a C alternative

c3.handmade.network

Post reply on HN
Print view View original

381–388 of 388 posts

Re: The case against a C alternative

#381

Post by usefulcat »

jstimpfle wrote: post #326
mort96 wrote: post #275

Earlier quoted context omitted.

There's nothing more complicated about using unique_ptr than a raw pointer, it just expresses who's responsible for calling `delete` explicitly in code rather than implicitly through program flow.

There's nothing complicated? You have to 1) #include 2) Write "std::unique_ptr foo" instead of just "My_Foo_Type *foo" in every definition. 3) Are required to define My_Foo_Type as a class with a separate deleter, or provide a deleter template argument at each declaration. 4a) write "foo.get()" in various places instead of just "foo". or 4b) lend around the unique_ptr in various places, breaking modularization and in…

I really don’t see what the big deal is? Generally the only time you should be returning or passing around a unique_ptr is when you’re actually transferring ownership of the referenced object. Otherwise just dereference it and pass around a reference to the underlying object.

Re: The case against a C alternative

#382

Post by jokoon »

xigoi wrote: post #352
jokoon wrote: post #193

Finally an article I can agree with. C is great mostly because it's easy to learn, and it has many other advantages. I dislike all those new languages because they have too many features, and they're non trivial to learn. I've looked at some rust codebases and I don't think there will be a lot of people who will want to maintain them. Rust is difficult, even though it's an awesome language. A language that could comp…

> easy to learn What exactly do you mean? Learn the basics? Become productive? Memorize the entire specification? I'd argue C isn't significantly faster at any of these than most other languages.

It can be learned quickly, it's very readable, and taught to students without too much pain, and beginners can become productive with it.

The "difficulty bar" must be low. This is why english is a popular language.

> I'd argue C isn't significantly faster at any of these than most other languages.

Yes it is. It has a lot of flaws, but it's popular for all those other reasons.

Re: The case against a C alternative

#384

Post by pkrumins »

dang wrote: post #165
pkrumins wrote: post #94

Earlier quoted context omitted.

Quoted post unavailable.

Would you please stop trolling HN? You've been here for 15 years. You have a distinguished history of writing good articles. You didn't use to post crap comments like this or https://news.ycombinator.com/item?id=32387218 and we need you to stop it. If you don't we will have to ban you, which I would hate to do. If you have some substantive critique to make about Rust in appropriate contexts, that's fine of course. Bu…

Dang, I apologize for these comments. Every time I tried Rust, I just couldn’t get anything done in a reasonable amount of time, and I started hating this language. I will refrain from commenting on Rust posts from now on.

Re: The case against a C alternative

#385

Post by mumblemumble »

water8 wrote: post #380
mumblemumble wrote: post #343

Earlier quoted context omitted.

This actually reminds me a bit of an old competition between two Microsoft MVPs comparing C++ and C#, where they went back and forth optimizing their respective versions of a model program, and discussing the optimizations they made. The gist, as I recall it was: the initial, idiomatic, written-for-maintainability version of the C# program was significantly faster than the C++ equivalent. Up until the end, the C# ver…

C# is closer to Java than C++. It’s a garbage collector language and nowhere near the performance of C++

So, one of the things they discovered as part of the back and forth was that C#'s generational garbage collector was actually an advantage. Because it made finding memory for a new object allocation O(1), while for C++ it was O(N).

That observation was actually key to the C++ version ultimately producing the fastest version. Chen replaced malloc() with an implementation that was tailored to the problem in question.

I guess the thing that I always find lacking in these discussions is a cost/benefit analysis. Yes, C++ will let you do things like that, and they will absolutely allow you to wring every last drop of performance out of what you're doing.

But, if you aren't in a situation where optimizing to that extent is cost-effective, and you're working in a business domain where frequent heap allocation of short-lived objects is what you do, so that idiomatic, standard C++'s default way of doing things is known to generally be not significantly better, and often slower, than some of the faster GC languages, then it's just possible that that you should go for the pragmatic option.

Re: The case against a C alternative

#386

Post by dang »

pkrumins wrote: post #384
dang wrote: post #165

Earlier quoted context omitted.

Would you please stop trolling HN? You've been here for 15 years. You have a distinguished history of writing good articles. You didn't use to post crap comments like this or https://news.ycombinator.com/item?id=32387218 and we need you to stop it. If you don't we will have to ban you, which I would hate to do. If you have some substantive critique to make about Rust in appropriate contexts, that's fine of course. Bu…

Dang, I apologize for these comments. Every time I tried Rust, I just couldn’t get anything done in a reasonable amount of time, and I started hating this language. I will refrain from commenting on Rust posts from now on.

Thanks! I appreciate the reply.

Re: The case against a C alternative

#387

Post by Tozen »

didip wrote: post #112

Jai is not real. It should not be mentioned even on the same sentence as Zig.

You can't say Jai is not real, because there are beta testers using it. However, there are other languages that have taken and implemented various concepts that Jai had to offer. By the time Jai comes out, and is open to the public, there might not be anything compelling about it anymore.

Re: The case against a C alternative

#388

Post by planede »

yakubin wrote: post #339
planede wrote: post #176

Earlier quoted context omitted.

inlining only goes so far. You won't get full of qsort to be inlined, and if it's not inlined, it needs to be at least cloned to be on par with std::sort, so the comparator function could get const-propagated. AFAIK out of the major compilers, gcc has the most aggressive cloning, but it's still nowhere near to const propagate the comparator from qsort. With std::sort with a stateless comparator function object (such…

glibc qsort's implementation is in libc.so, not in the header. GCC doesn't have anything to work with. It's also an apples-to-oranges comparison, since std::sort and qsort implement different algorithms. A lot of std::sort's performance is actually from using the version without any callbacks. If you pass a comparator function which just compares two integers the obvious way, it gets much slower. So one of std::sort'…

> If you pass a comparator function which just compares two integers the obvious way, it gets much slower. So one of std::sort's biggest advantages is actually not that it uses templates, but that it's specialized for the common case of not needing a custom callback.

This is not true. `std::sort`'s default comparator is a `std::less` object. The advantage comes from using a stateless callback functor object. If you pass a capture-less lambda instead of a function pointer, you can reap the same benefits as using the default comparator. Even if that capture-less lambda just forwards to a specific free function anyway.

In short, `std::sort(beg, end, [](auto x, auto y) { return foo(x,y); })` can be faster than `std::sort(beg, end, &foo)`.

Post reply on HN