Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The issue with safer c++ and modern c++ is the mirror of the problem with migrating a code base from c++ to rust. There is just so much unmodern and unsafe c++ out there. Mixing modern c++ into older codebases leaves uncertain assumptions everywhere and sometimes awkward interop with the old c++. If there was a c++23{} that let the compiler know that only modern c++ and libc++ existed inside it would make a huge difference by making those boundaries clear and you can document the assumptions at that boundary. Then move it over time. The optimizer would have an advantage in that code too. But they don't want to do that. The least they could do is settle on a standard c++abi to make interop with newer languages easier, but they don't want to do that either. They have us trapped with sunk cost on some gaint projects. Or they think they do. The big players are still migrating to rust slowly, but steadily.


There kind of is. There's __cplusplus, which I'll grant you is quite janky.

  #IF __cplusplus==202302L


That checks whether a C++ compiler is used and, if so, for the version of the compiler, not whether “only modern c++ and libc++ existed inside it”.

C++ compilers carry lots of baggage for backwards compatibility.


I'm wondering if the C++ -> Rust converters out there are part of the Solution: After converting C++ to Rust, then convert Rust to C++ and you now have clean code which can continue to use all the familiar tooling.


> I'm wondering if the C++ -> Rust converters out there are part of the Solution

Are there C++-to-Rust converters? There are definitely C-to-Rust converters, but I haven't heard of anyone attempting to tackle C++.

> After converting C++ to Rust, then convert Rust to C++ and you now have clean code which can continue to use all the familiar tooling.

This only works if a hypothetical C++ to Rust converter converts arbitrary C++ to safe Rust. C++ to unsafe Rust already seems like a huge amount of work, if it's even possible in the first place; further converting to safe Rust while preserving the semantics of the original C++ program seems even more of a pie in the sky.


Presumably you migrate to this Rustic++ version implying it's maintainable.


I'm not questioning what you do once you get to that hypothetical Rustic++. I'm questioning whether it's possible to get there using automated tooling in the first place.


I think you have a point. Rustic++ won't be vibe-coded in a weekend.


> There is just so much unmodern and unsafe c++ out there. Mixing modern c++ into older codebases leaves uncertain assumptions everywhere and sometimes awkward interop with the old c++

Your complaint doesn’t look valid to me: the feature in the article is implemented with compiler macros that work with old and new code without changes.

See https://libcxx.llvm.org/Hardening.html#notes-for-users


Thats true, going bottom up is easier. Old c++ making calls into modern c++ or rust is less of a problem than the other way.


And not everywhere, as there are many industrial scenarios where Rust either doesn't have an answer yet, or is still in early baby steps regarding tooling and ecosystem support.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: