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

41–50 of 80 posts

Re: C++ to Rust Phrasebook

#41

Post by pjmlp »

m-schuetz wrote: post #21
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.

Depends on which requirements one has.

If staying only on VC++ or clang latest, with MSBuild or CMake/ninja, they kind of are, on my hobby coding I have been using modules for quite a while now, check the C++ projects on Github.

Tip, for node native modules, which node-gyp probably will never support them, they are supported via cmake.js.

Re: C++ to Rust Phrasebook

#42

Post by amelius »

pornel wrote: post #37
amelius wrote: post #28

Earlier quoted context omitted.

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

Wrong is too strong. The code is okay given the constraint — this is a guide for C++ programmers thinking in C++ terms, not for teaching purely idiomatic Rust from the ground up.

Ok, do you have any examples to convince me?

Re: C++ to Rust Phrasebook

#43

Post by pjmlp »

jpc0 wrote: post #34
skrishnamurthi wrote: post #9

Earlier quoted context omitted.

It's definitely written from the perspective of someone who "knows C++". But I put that in quotes because there are (at least) two interpretations of that phrase. There's the person who doesn't know any C++ at all, and for that person, this is useless. But there's the person who knows a baseline of C++ but doesn't know modern C++, and they can use this as a way to modernize their C++ code while ignoring the Rust bits…

There are patterns diffused in this paper that are modern C++ only in the sense that anything post C++11 is modern C++. That was 14 years ago, you will be hard pressed to find a toolchain that doesn’t support C++17 at this point, yes there is probably some unfortunate person building for debian old-stable or some ancient but still supported redhat but at that point you know you aren’t following modern practices and y…

I will also debate that plenty of "modern" C++ features that people attribute to C++11, were already possible throughout C++ARM to C++03, but apparently many either weren't paying attention, or only renaming their C files into .cpp/.cxx/.C.

Just like the low level stuff done by MFC, and how much more ergonomic CSet++, OWL and VCL happened to be.

Re: C++ to Rust Phrasebook

#44

Post by jandrewrogers »

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++?

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.

Re: C++ to Rust Phrasebook

#45

Post by m-schuetz »

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

Earlier quoted context omitted.

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.

Ctrl+, followed by f filename , you will get the file. The only reasons I use VSCode are the plugins I cannot get on VS, like Powershell, Rust, Azure tooling, and for stuff like Next.js, better use an editor that is anyway a browser in disguise. Performance has never been a part of my decision flowchart.

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.

Re: C++ to Rust Phrasebook

#46

Post by pjmlp »

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

Earlier quoted context omitted.

Ctrl+, followed by f filename , you will get the file. The only reasons I use VSCode are the plugins I cannot get on VS, like Powershell, Rust, Azure tooling, and for stuff like Next.js, better use an editor that is anyway a browser in disguise. Performance has never been a part of my decision flowchart.

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.

Re: C++ to Rust Phrasebook

#47

Post by sunshowers »

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.

So the existence of an object of the type does not act as a static proof that the state is valid?

Re: C++ to Rust Phrasebook

#48

Post by sunshowers »

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.

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

Re: C++ to Rust Phrasebook

#49

Post by leoh »

pjmlp wrote: post #14
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…

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.

Re: C++ to Rust Phrasebook

#50

Post by steveklabnik »

sunshowers wrote: post #47
jandrewrogers wrote: post #44

Earlier quoted context omitted.

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.

So the existence of an object of the type does not act as a static proof that the state is valid?

That’s correct, and “valid but unspecified state” is possible/common too.
Post reply on HN