It's time to halt starting any new projects in C/C++ • Hacker News Board

Re: It's time to halt starting any new projects in C/C++

#891

Post by ncmncm » Wed, Sep 21, 2022, 1:19 PM UTC

sophacles wrote: post #886

ncmncm wrote: post #870

Earlier quoted context omitted.

I like Rust fine. But Rust is not suitable for my work, where C++ is. So, anyone saying "no programs should be written in C++" is saying, exactly, that I should not be able to do my work, and that I should not have employment. That my current employer will not necessarily obey such an instruction does not make the attempt any the less offensive.

It's finally clear - You don't actually think that people are advocating for you to be fired[1]. You are just taking an absurd extreme position because after a career of not having to think too much about other languages something comes along that can actually threaten the C++ crown. Now you are worried that you'll be relegated to the niches along with your language, like assembler and cobol. Don't worry - there'll b…

Try to explain the difference between "no new projects" and "no programs". Any program I have not written yet would be a new project. Any old project is one where the program has already been written.

So you are being dishonest in pretending to a distinction without a difference.

Switching from the legitimate "you should use my new language because it is good" to "you should demote everybody coding to legacy maintenance, and put us in their place" admits a very ugly fact about yourselves and about your beliefs about your language's legitimate prospects.

If you believed it deserves a place on its own merits, you would not be trying to tear down other languages to try to make a hole for it. It is disgraceful behavior.

You should be ashamed of that, and you should be more ashamed of calling people who object "delusional".

Re: It's time to halt starting any new projects in C/C++

#892

Post by throwaway2037 » Wed, Sep 21, 2022, 1:33 PM UTC

woodruffw wrote: post #75

throwaway2037 wrote: post #67

Earlier quoted context omitted.

I would call myself an average C++ programmer. Starting with move semantics in C++11 (very cool!), I found myself frequently making bugs by re-using an "already moved" container (like a vector). I couldn't find any simple way to avoid that mistake. And, from my tooling, it was a hard problem to debug, as are double frees. Do you have any advice to avoid re-using "already moved" containers?

Nothing great, unfortunately -- C++'s decision to leave moved-from values in a "valid but unspecified" state makes a lot of sense from a memory corruption perspective, but has caused plenty of logic bugs in my codebases as well. The best thing I've used so far is clang-tidy (specifically the "use-after-moved"[1] check). It catches some stuff though, which is better than nothing. [1]: https://clang.llvm.org/extra/clan…

Good point about clang-tidy. JetBrain's C++ IDE called CLion directly integrates clang-tidy. It is scary how good are some of the suggestions. Absolutely, it makes me a better C++ programmer! It feels like an oldster is tapping me on the shoulder while pair programming: "That one, over there, fix it."

Re: It's time to halt starting any new projects in C/C++

#893

Post by throwaway2037 » Wed, Sep 21, 2022, 1:37 PM UTC

ncmncm wrote: post #452

kllrnohj wrote: post #145

Earlier quoted context omitted.

It's well defined safe to use a vector after a move: Move constructor. Constructs the container with the contents of other using move semantics. Allocator is obtained by move-construction from the allocator belonging to other. After the move, other is guaranteed to be empty(). https://en.cppreference.com/w/cpp/container/vector/vector Which can be a useful property at times, but also means tooling won't help you here…

What he probably means is he imagines the moved-from vector still has elements in it, and indexes into the empty. Another argument for at() outside loops.

Yes, and most algorithms are "surpising" when a container is empty. Most people write, then read, algorithm code imagining a container full of elements. I've been caught by that "bug" so many times, that I now annotate (Java) when containers can be empty. The first few times co-workers see it, they are confused. They they re-read the code, and "oh, I get it. when empty, the code path is very different!" Unlike nullable values, empty collections (usually) don't cause exceptions.

Re: It's time to halt starting any new projects in C/C++

#894

Post by cercatrova » Wed, Sep 21, 2022, 1:59 PM UTC

ncmncm wrote: post #891

sophacles wrote: post #886

Earlier quoted context omitted.

It's finally clear - You don't actually think that people are advocating for you to be fired[1]. You are just taking an absurd extreme position because after a career of not having to think too much about other languages something comes along that can actually threaten the C++ crown. Now you are worried that you'll be relegated to the niches along with your language, like assembler and cobol. Don't worry - there'll b…

Try to explain the difference between "no new projects" and "no programs". Any program I have not written yet would be a new project. Any old project is one where the program has already been written. So you are being dishonest in pretending to a distinction without a difference. Switching from the legitimate "you should use my new language because it is good" to "you should demote everybody coding to legacy maintena…

> Any program I have not written yet would be a new project. Any old project is one where the program has already been written.

That is simply not any definition I've ever heard for a new project. You are assuming a binary of written or not written, and yet there are codebases that are incompletely written. That is what the parent means about ongoing projects that wouldn't migrate to Rust where you'd still be able to work on them, and who knows, maybe Rust won't overtake C++ and it'll continue, like many C projects have.

But that you have made yourself a "C++ developer," and not a developer in general who solves problems with whatever tool is best, does mean that whenever something comes along that threatens your identity, you seem to take it to absurdity, as the parent says.

Re: It's time to halt starting any new projects in C/C++

#895

Post by snovv_crash » Wed, Sep 21, 2022, 2:08 PM UTC

sophacles wrote: post #889

snovv_crash wrote: post #874

Earlier quoted context omitted.

Rust only released 1.0 in 2015. If you want to complain about pre-C++11 features, I would like to complain about Rust's garbage collector.

Did rust have a GC at some point pre-1.0? Interesting. Not sure how limiting the discussion of a language to just the features included in the 3rd standard and forward makes sense. Particularly when the old stuff is still present and valid in the later standards. Just because you want to use some convention curtain off some area of the language doesn't mean it's not there.

https://pcwalton.github.io/_posts/2013-06-02-removing-garbag...

This came 2 years after C++11 was finalized, which introduced RAII memory management, threads, range loops and much more, and is the basis for modern C++.

Of course, there are pros and cons to keeping backwards compatibility with old code. Personally I think it's an amazing technical achievement that the same code written in 1987 still works. Particularly for numerical work there are a lot of libraries that would be a massive pain to rewrite correctly, just getting them off of Fortran was an achievement.

In terms of new and old standards coexisting in the same code, of course it isn't preferable, but it is possible which can enable many use cases, eg. in place upgrades. Forcing rewite-the-world is what caused the Python 2 --> 3 migration to be such a mess.

And if you really don't want old features, there are linter rules and compiler warnings which do a great job for this.

Re: It's time to halt starting any new projects in C/C++

#896

Post by gpm » Wed, Sep 21, 2022, 3:08 PM UTC

orlp wrote: post #877

gpm wrote: post #718

Earlier quoted context omitted.

> I meant counted references that were mentioned as an alternative in the GP comment. The main problem with reference counted pointers is detecting cycles. Rust doesn't have a cycle detector, but only a concept of "weak" pointers that don't prevent the object they're pointing at from being destroyed, just detect if it has been. This works fine if you have a tree with parent pointers, you make the parent pointers weak…

Hey, slotmap author here. Once I get around to slotmap 2.0 (as noted by my inactivity, I haven't had much of the good free time + energy combination last year), the default behavior will be to leak the memory of a slot after 2^31 alloc/free pairs in that slot rather than wrapping around. You can still get the old wrapping behavior, but the default will be to never, ever allow spurious references, at the cost of leaki…

Hey, thanks for the great library :)

> I don't think the overhead is as large as this implies. For SlotMap the memory overhead is ~4bytes plus alignment per element, and insertion/deletion is only a handful instructions and one branch extra compared to a vector push:

I think they were imagining one generation counter for the entire map instead of one per slot. I agree it's not particularly high.

Re: It's time to halt starting any new projects in C/C++

#897

Post by gpm » Wed, Sep 21, 2022, 3:10 PM UTC

dusklight wrote: post #875

gpm wrote: post #228

Earlier quoted context omitted.

The borrow checker has become smarter, but not at handling cyclic data structures. The problem you're describing still exists, though I'd say the advice isn't quite right. Generally the better advice is to use a graph library, or something like slotmap [1] if you're rolling your own, than to use a Vec or HashMap. That's superior to a vec/hashmap for a few reasons. It handles keeping indicies stable/writing your own i…

what do most people use for a generic graph / tree library in rust?

For "proper" graphs, petgraph: https://crates.io/crates/petgraph

For trees without parent pointers: Just roll your own along the lines of the following. This fits nicely into rust's ownership semantics

    struct Node {
        children: Vec>
    }

For trees with parent pointers, I'm not sure what's most common. Potentially Rc with Weak, potentially petgraph, maybe something else.

Re: It's time to halt starting any new projects in C/C++

#898

Post by gerbs » Wed, Sep 21, 2022, 3:11 PM UTC

fsloth wrote: post #334

jandrewrogers wrote: post #306

Earlier quoted context omitted.

In fairness, using integer handles instead of pointers is pretty idiomatic in high-performance C++ too. I've never found it to be onerous or complicated.

Yes, using integers is not a handicap in many cases but default way of addressing.

Hey, I'm a college student majoring in Physics and wanted to ask for your email. A lot of my interests mirror yours and I want some guidance from someone who has experience with them.

I know this is out of the blue, but I really want to get in contact with you. Thanks.

Re: It's time to halt starting any new projects in C/C++

#899

Post by [deleted] » Wed, Sep 21, 2022, 3:23 PM UTC

ncmncm wrote: post #891

sophacles wrote: post #886

Earlier quoted context omitted.

It's finally clear - You don't actually think that people are advocating for you to be fired[1]. You are just taking an absurd extreme position because after a career of not having to think too much about other languages something comes along that can actually threaten the C++ crown. Now you are worried that you'll be relegated to the niches along with your language, like assembler and cobol. Don't worry - there'll b…

Try to explain the difference between "no new projects" and "no programs". Any program I have not written yet would be a new project. Any old project is one where the program has already been written. So you are being dishonest in pretending to a distinction without a difference. Switching from the legitimate "you should use my new language because it is good" to "you should demote everybody coding to legacy maintena…

[deleted]

Re: It's time to halt starting any new projects in C/C++

#900

Post by bowlerman » Wed, Sep 21, 2022, 5:15 PM UTC

ghoward wrote: post #837

stouset wrote: post #823

Earlier quoted context omitted.

> But I've spent gobs of time trying to understand async/await and failed. It wasn't as much time as I spent honing my C, but it was a lot. And I did not seem to make progress. I've said this elsewhere but as a long-time Rust user I have literally never used or even encountered async/await. It exists, and I could use it if I needed to, but I never have nor have I had to spend effort avoiding it or thinking about it.…

I'm glad you said this because my impression of Rust async/await until now was that it was unavoidable, mostly because I heard that all of the big-name crates, the ones you would use in just about every project, use async/await.

Big-name crates that do IO often use async by default, but I haven't seen one so far that doesn't provide a sync/blocking api as well. Usually this is done by enabling a feature for the crate.