Live data from Hacker News

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

twitter.com

101–110 of 929 posts

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

#101
post #79

Earlier quoted context omitted.

> How is Rust so much more secure and reliable than *modern* C++? Rust catches things like use-after-free at compile time. *modern* C++ still lets things slip through e.g. #include #include #include int main() { std::string s = "Hellooooooooooooooo "; std::string_view sv = s + "World\n"; std::cout

If by "slip through", you mean "warns you about by default", then yes it lets it slip through. clang++ -std=c++17 test.cc a.cc:7:29: warning: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling-gsl] std::string_view sv = s + "World\n"; ^~~~~~~~~~~~~ In any case, I think the philosophical differences between C++ and Rust are well understood, and the different views of the cost/be…

> If by "slip through", you mean "warns you about by default", then yes it lets it slip through.

My bad. I should have been more modern. Try this one:

    #include 
    #include 
    #include 

    int main() {
      std::string s = "Hellooooooooooooooo ";
      std::string_view sv {s + "World\n"};  // {now even more modern and warning free}
      std::cout 

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

#102
post #66

Earlier quoted context omitted.

You see it a lot more often from the Microsoft world since MSVC only supported "C/C++" as a combined language, there was no separate C compiler.

They had a C compiler for kernel drivers.

Really? I don't know much about microsoft's internal architecture after Windows 98. But they maintained a separate compiler for what was basically just kernel modules?

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

#103

Earlier quoted context omitted.

you can use no_std when available. not sure how dynamic linking would help when your boards don’t have enough (flash ?) space… the linked library still needs to go somewhere? how small of a flash medium are you using?

yes no_std for kernel or boot code or MCU boards, that's what rust-embedded is doing and I think it's fine. many embedded boards typically have 16~64MB Flash running Linux with musl, one rust binary statically linked can easily exceeding 10MB. multi-entry is hard to manage when you have quite a few unrelated tasks, so yes I really need a true shared lib based rust for the mid-range embedded boards, which are, quite a…

I'm not sure what you mean by multi-entry, but it's hard to beat a busybox-style binary for code-size, especially with LTO. If you're building everything into a single filesystem image anyways, this is almost always smaller than dynamic linking.

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

#104
post #79

> For the sake of security and reliability. I just read a few C++ vs Rust comparisons online yesterday and didn't see anything about a significant difference in security or reliability. Mind you the articles weren't very technical. How is Rust so much more secure and reliable than *modern* C++?

> How is Rust so much more secure and reliable than *modern* C++? Rust catches things like use-after-free at compile time. *modern* C++ still lets things slip through e.g. #include #include #include int main() { std::string s = "Hellooooooooooooooo "; std::string_view sv = s + "World\n"; std::cout

I mean I get it. On the other hand you really should know the constructs you are using. std::string_view is essentially a reference to a char array and you are assigning a temporary object (r-value) to it. Standard C++ rules say that you can't expect the lifetime of that object hold past the expression.

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

#106

Earlier quoted context omitted.

If by "slip through", you mean "warns you about by default", then yes it lets it slip through. clang++ -std=c++17 test.cc a.cc:7:29: warning: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling-gsl] std::string_view sv = s + "World\n"; ^~~~~~~~~~~~~ In any case, I think the philosophical differences between C++ and Rust are well understood, and the different views of the cost/be…

Quoted post unavailable.

For trivial examples like this, it's easy to spot.

For modifications on a large codebase months (or years) after the original code happened, it saves significant time and effort to have the compiler catch bugs like this at compile time.

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

#108

Earlier quoted context omitted.

If we did that, the Rust folks wouldn't be able to claim credit for the colossal amount of very important code written in C and C++ that gets ported over to Rust. I've never seen a language where feathers in the cap are more important than they are to the Rust community.

Gosh, every Rust post feels like Thanksgiving dinner. Let's settle down. > ... if we used all the effort gong (sic) to develop Rust and port everything over to Rust to instead just improve the wrinkles that exist in C++. If you read the tweet, you might notice Mr. Russinovich isn't actually advocating porting everything to Rust. If you'd care to explain how one might iron out the little wrinkles in C++, you have a ca…

So he is just complaining without proposing any real solutions then?

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

#109

Someone else downthread: "young developers can pick up Rust quite fast, and that makes it vastly easier than trying to find talented C/C++ developers." I hope so. I have a hypothesis that the big-O for language success is "How easily can new programmers learn it?" Nothing else matter. JavaScript was slow, but everyone learned it, so it got fast. Python still had bad tooling, but everyone learned it, so it got better.…

Dunno. Young devs can pick basic Rust constructs fast but when it comes to complicated stuff where performance is critical... There must be raw talent and lot of grind. IMO it's easier to write super complex stuff in C++ than in Rust as there are just too many cognitive things to keep in mind in Rust to even compile. C++ for talented folks makes life easier there. Like JavaScript, yet another language written for bad to average developers to keep them from shooting themselves in the foot.

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

#110
post #91

The volume of existing C, C++, Objective-C, and C# code is phenomenal. Even if this strategy is generally adopted there will continue to be lots of this legacy code for many years to come. In particular there will continue to be such legacy code right up until 2038 at least.

carbon, and the newly announced alpha stage efforts called cppfront, can potentially act as a "typescript" for c++, new compiler can enforce memory safety at an upper layer before they're converted to c++, maybe there is hope for c/c++ code for years to come as long as they keep fixing issues along the way.

Having written enough Rust code, I could bet that it won't be an easy task to rewrite C/C++ code with a borrow checked language. You just need to write code differently for this approach to work.
Post reply on HN