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

21–30 of 80 posts

Re: C++ to Rust Phrasebook

#21

Post by m-schuetz »

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…

Are C++ modules actually production ready now? Last I checked, they still weren't properly supported accross all major compilers.

Re: C++ to Rust Phrasebook

#22

Post by EliRivers »

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…

To be fair, there's a reason for the pattern with init methods you're describing.

Without prejudice on any other reasons, the most common reason for this pattern I've seen is people thinking in languages that basically don't have constructors, yet writing C++. It's not a good reason.

Re: C++ to Rust Phrasebook

#23

Post by Mond_ »

EliRivers wrote: post #22
atq2119 wrote: post #12

Earlier quoted context omitted.

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…

To be fair, there's a reason for the pattern with init methods you're describing. Without prejudice on any other reasons, the most common reason for this pattern I've seen is people thinking in languages that basically don't have constructors, yet writing C++. It's not a good reason.

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

Re: C++ to Rust Phrasebook

#24

Post by Mond_ »

90s_dev wrote: post #6

I will be using this to learn both Rust and C++ and see which one I like better.

This isn't much of a tutorial or learning guide, it's a lookup table that roughly pattern matches C++ to Rust.

Probably not the best place to start learning.

Re: C++ to Rust Phrasebook

#25

Post by pornel »

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…

The worst pitfall is Rust references == pointers.

They are implemented as pointers, but their role is to give temporary (often exclusive) access that is restricted to a statically know scope, which is pretty specific and fits only some uses of some pointers/C++ references. In C++ pointers typically mean avoiding copying, but Rust references avoid storing/keeping the data. When these goals don't overlap, people get stuck with a dreadful "does not live long enough" whack-a-mole.

Re: C++ to Rust Phrasebook

#26

Post by metaltyphoon »

Mond_ wrote: post #23
EliRivers wrote: post #22

Earlier quoted context omitted.

To be fair, there's a reason for the pattern with init methods you're describing. Without prejudice on any other reasons, the most common reason for this pattern I've seen is people thinking in languages that basically don't have constructors, yet writing C++. It's not a good reason.

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

This was one of the best decisions that Rust and Go did; not have constructors. In C# this is super annoying too, specially when you need an async operation to construct a type. This is usually done by having an private constructor and then using a static public method to create the type.

Re: C++ to Rust Phrasebook

#27

Post by pornel »

amelius wrote: post #18

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

C++ syntax and semantics are optimized for C++ idioms, and Rust's aren't.

Rust is more related to ML-family languages than C-family and OOP, so it needs to "emulate" some C++ idioms.

This goes both ways, e.g. equivalent of Rust's pattern matching on enums with data translates to verbose and clunky C++.

Re: C++ to Rust Phrasebook

#28

Post by amelius »

pornel wrote: post #27
amelius wrote: post #18

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

C++ syntax and semantics are optimized for C++ idioms, and Rust's aren't. Rust is more related to ML-family languages than C-family and OOP, so it needs to "emulate" some C++ idioms. This goes both ways, e.g. equivalent of Rust's pattern matching on enums with data translates to verbose and clunky C++.

So you are saying that this approach teaches C++ users to use the wrong idioms in Rust?

Re: C++ to Rust Phrasebook

#29

Post by NotCamelCase »

m-schuetz wrote: post #20
pjmlp wrote: post #15

Earlier quoted context omitted.

Visual Studio and Clion are the ones currently with the best experience regarding modules. And in VS could be much better, but EDG has other priorities. VSCode isn't really that great option for C/C++.

I prefer vscode simply because VS is excruciatingly slow. e.g. the file open pane in vscode pretty much instantly lists the file I'm looking for, while the counterpart in VS (ctrl+,) takes several seconds and intermixes search results for files and file contents, when I'm only interested in files.

> VS (ctrl+,) takes several seconds and intermixes search results for files and file contents, when I'm only interested in files.

I hate this a lot. It's gotten so bad the last couple of releases to the point that I try and use VS Code more in lieue of VS except debugging.

How they could let such fundamental functionality get broken is beyond me.

Re: C++ to Rust Phrasebook

#30

Post by jpc0 »

IshKebab wrote: post #13
Toritori12 wrote: post #11

Earlier quoted context omitted.

C++ modules still not supported on VSCode, always pissed when I get notifications from this 5 y.o. thread [0]. 0: https://github.com/microsoft/vscode-cpptools/issues/6302

Does Clangd support it? It's much better than Microsoft's C++ extension - and open source!

Yes this.

Clangd-19 which is current stable has very good support for modules. The only issues I’ve encountered is with import std; which quite honestly is bleeding edge.

Your tooling (clangd+cmake) has to be pretty modern t those two are also the easiest to just upgrade since it’s dev time only. And obviously if it’s a discussion you have a C++20 compatible compiler. I’m happily using modules with gcc-14, clangd 19 and cmake 3.28 other than clangd 19 those are just packages you can install in Ubuntu 24.04 which is over a year old at this point.

Post reply on HN