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

11–20 of 80 posts

Re: C++ to Rust Phrasebook

#11

Post by Toritori12 »

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…

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

Re: C++ to Rust Phrasebook

#12

Post by atq2119 »

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 adopted a pattern where the constructor is private in this case and the object construction can be done with static methods - which is a bit more like Rust, actually.

Re: C++ to Rust Phrasebook

#13

Post by IshKebab »

Toritori12 wrote: post #11
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…

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!

Re: C++ to Rust Phrasebook

#14

Post by pjmlp »

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 backgrounds and their own agendas, companies whose IT refuses to upgrade, the amount of implementations in the industry increases, teachers not bothering to keep up to date,...

Re: C++ to Rust Phrasebook

#15

Post by pjmlp »

Toritori12 wrote: post #11
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…

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

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

Re: C++ to Rust Phrasebook

#16

Post by pjmlp »

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…

I hate with passion two phase initialisation, C++ libraries that are bare bones C libraries wrapped in an extern "C" { }, malloc()/free(), C style coding and such.

Re: C++ to Rust Phrasebook

#17

Post by legobmw99 »

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…

This is fine if the method you’re talking about is static — as you point out, it’s really all Rust has — but is absolutely a design mistake if it is not, which I think is what the poster above is referring to. It’s a common anti pattern and means you have an object that is at-best useless and at-worst completely broken after you call the constructor but before you call some member function on it

Re: C++ to Rust Phrasebook

#19

Post by TuxSH »

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…

Two-phase initialization also has the added benefit of usually making the object have a constexpr constructor (usually a default constructor) and therefore making it eligible for constinit.

That said, construct_at also exists.

Re: C++ to Rust Phrasebook

#20

Post by m-schuetz »

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

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.
Post reply on HN