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

C++ to Rust Phrasebook

cel.cs.brown.edu

Post reply on HN
Print view View original

61–70 of 80 posts

Re: C++ to Rust Phrasebook

#61

Post by m-schuetz »

pjmlp wrote: post #46
m-schuetz wrote: post #45

Earlier quoted context omitted.

I know it gets you the file...after several seconds. Vscode gives it instantly. I use this feature so often, it's basically a dealbreaker for VS. I keep both editors open, but VS is basically just there to hit the compile button and for the occasional debugging.

Dunno, time to check your plugins slowing down the IDE. Better not having Resharper around.

I have zero plugins installed. VS is just so slow that it's even outmatched by a javascript/Electron app like vscode.

Re: C++ to Rust Phrasebook

#62

Post by fooker »

atq2119 wrote: post #12
EliRivers wrote: post #3

One of the common pitfalls I've seen in my time is someone writing a language they are familiar with in a language that just doesn't fit; trying to apply idioms that flow well with one language to another language where that's just not a good way to achieve the same ends. An example I've seen a lot is a C thinker writing C++ classes with an init() function; sure, it works, but the C++ way is to do that in constructor…

To be fair, there's a reason for the pattern with init methods you're describing. C++ constructors can't return values. If construction is fallible, the only way to communicate the error is via C++ exceptions. If you're in a code base that embraces exceptions, that's fine. But (C++) exceptions kind of suck, so many code bases don't, and then you have to find some alternatives. Over the years, I've increasingly adopte…

Right, when construction is fallible you need a factory.

Constructors are called in surprising places when running a C++ program. For example, think of a copy constructor failing somewhere far away from the code you are writing. If C++ allowed construction to fail, the control flow of propagating these errors would be tedious and invasive.

Hence exceptions as the only way to fail in a construction.

Re: C++ to Rust Phrasebook

#63

Post by steveklabnik »

modulus1 wrote: post #55
amelius wrote: post #18

I noticed that for most of the examples the Rust version is more verbose.

And they even made the C++ version more verbose than it should have been. Most people would write: class Person { int age = 0; }; I wish rust would make default struct field values this easy to write.

It’s coming soonish! There’s an accepted RFC that’s getting close to being ready to stabilize https://github.com/rust-lang/rust/issues/132162

Re: C++ to Rust Phrasebook

#64

Post by atq2119 »

jandrewrogers wrote: post #44
Mond_ wrote: post #23

Earlier quoted context omitted.

How would you deal with fallible construction of objects while avoiding exceptions in idiomatic C++?

The standard idiom is to have a sentinel state for the object indicating it is invalid. For objects without trivial destructors or which may be read after being moved-from (a valid behavior in some systems code contexts) then you need a sentinel state anyway because moves in C++ are non-destructive. C++ uses deferred destruction as a standard tool to solve a variety of problems.

This makes sense for objects that can enter an equivalent invalid state after successful construction as the result of a method call (e.g. a file or stream).

For objects that don't have that property, you're just exchanging one kind of badness in the design for a different but ultimately equivalent badness.

Re: C++ to Rust Phrasebook

#65

Post by eslaught »

leoh wrote: post #49
pjmlp wrote: post #14

Earlier quoted context omitted.

As someone that has been around C and C++ communities since 1990's, I also expect that in the long term Rust won't be able to escape this phenomenon, even with editions. Like any other programming language that has made it into the top 10 over several decades of production code. The happy path will get fuzzier, as more humans have their own opinion on what means to write code on the ecosystem, with various kinds of b…

Hasn't been the case the last 10y. If anything there has been convergence.

Async vs. non-async is the main example today. There are libraries that support one or the other, or sometimes one library will have two usage modes (effectively two different code bases) because you can't really mix them.

In the future who knows, because we don't know what features will get added to the language.

Re: C++ to Rust Phrasebook

#66

Post by atq2119 »

pjmlp wrote: post #40
Mond_ wrote: post #23

Earlier quoted context omitted.

How would you deal with fallible construction of objects while avoiding exceptions in idiomatic C++?

Idiomatic C++ uses exceptions. The standard doesn't allow to disable language features. Anyone that goes into the dark side of disabling language features is writing unidiomatic C++ with compiler specific extensions.

That's a bold statement, considering that many of the largest C++ code bases - including at least one of the few remaining C++ compilers! - don't use exceptions.

Re: C++ to Rust Phrasebook

#67

Post by dwattttt »

jpc0 wrote: post #7

There are so many different flavours of C++ put there that this guide doesn’t exactly do itself the credit it deserves. There are easy ways to implement stuff like enums with members in C++, just put an anonymous enum inside a class/struct, its possible but marked as not possible. Likewise when discussing modules in rust while completely ignoring the existence of modules in C++ that is actually support by modern tool…

> There are easy ways to implement stuff like enums with members in C++, just put an anonymous enum inside a class/struct, its possible but marked as not possible.

This guide does exactly that in C++ for methods on enums.

For members, won't this result in all instances of an "enum" having all fields? That's not really comparable to Rust enums, if that's what you mean.

Re: C++ to Rust Phrasebook

#68

Post by surajrmal »

eslaught wrote: post #65
leoh wrote: post #49

Earlier quoted context omitted.

Hasn't been the case the last 10y. If anything there has been convergence.

Async vs. non-async is the main example today. There are libraries that support one or the other, or sometimes one library will have two usage modes (effectively two different code bases) because you can't really mix them. In the future who knows, because we don't know what features will get added to the language.

std vs nostd is another big one. Within nostd there are a ton of tiny fragmented worlds. For example, the Linux kernel ecosystem will likely development its own flavor of rust, especially when it comes to memory model. Old Linux distributions will end up with fairly ancient compiler versions that require code to stick to older conventions. I doubt well end up with people stuck on targeting c89 sort of situations, but things may trend in that general direction.

If you develop that for servers or mobile/desktop applications it might look more homegenous, but their are a lot of segments beyond those out there.

Re: C++ to Rust Phrasebook

#69

Post by pjmlp »

atq2119 wrote: post #66
pjmlp wrote: post #40

Earlier quoted context omitted.

Idiomatic C++ uses exceptions. The standard doesn't allow to disable language features. Anyone that goes into the dark side of disabling language features is writing unidiomatic C++ with compiler specific extensions.

That's a bold statement, considering that many of the largest C++ code bases - including at least one of the few remaining C++ compilers! - don't use exceptions.

I love bold statements, and if you mention either LLVM or Chrome, it isn't as if the Google's C++ style guide is any piece of art.

Which anyone that bothers to make such claims, should be aware what it actually says regarding exceptions.

"On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions."

They don't use exceptions, because already started on the wrong foot, and like legacy code of Titanic size there is no turning around now.

What does the Bible of idiomatic C++ says, aka C++ Core Guidelines?

It has several advices on E section, regarding exception coding best practices.

Re: C++ to Rust Phrasebook

#70

Post by pjmlp »

sunshowers wrote: post #48
pjmlp wrote: post #40

Earlier quoted context omitted.

Idiomatic C++ uses exceptions. The standard doesn't allow to disable language features. Anyone that goes into the dark side of disabling language features is writing unidiomatic C++ with compiler specific extensions.

Can you think of good reasons why an organization would hesitate to use C++ exceptions?

Legacy code writen as if it was C with a C++ compiler, or that predates the C++98 standard (during the 1980-90's, where C++ARM was the only guidance), the Orthodox C++ folks, claiming that they are too slow or bloated (most of the time based on hearsay and not profiled), on embedded computers better than everything I owned since 1980's until 2000's, put together.

The same folks won't have a second thought distributing statically linked binaries that triple the size, while using languages that don't do exceptions, but then it isn't bloat, talk about being coherent.

Post reply on HN