HN Explorer

29 comments

[ 2.8 ms ] story [ 77.0 ms ] thread
kibwen
The OP is likely nothing more than wishful thinking, but I can see why people are intrigued by the prospect. An important thing to note is that it's entirely possible to perform a slow, gradual integration of Rust code into a C/C++ codebase (such as Mozilla is doing with Firefox), but only if your codebase is sufficiently modular with well-defined interfaces for Rust-based libs to slot into. If all you've got is a big ball of mud, then your first step is to work on the modularization of your codebase (which, IMO, has a good chance of increasing your code quality regardless of whether you eventually decide to introduce any Rust).
alexnewman
You end up having to toss a layer of c around your c++ last time I checked. Does c++ even have an abi yet?
roblabla
well, not a standard one. That's what extern "C" is for : if you want a standardized API, C always had one.
[deleted]
(comment deleted)
gpderetta
Neither C nor C++ have a standardized ABI, if by standardized you mean part of their respective ISO standard. Nor they could, as the many of ABI properties (names, calling conventions, layout, object and executable file format) are intimately platform (as in OS and CPU) specific.

Most platform officially specify their C ABI, and many also specify their C++ ABI (usually in therm of the C one). Itanium C++ ABI (plus the platform specific psABIs) has become the de facto C++ ABI for many unix and unix-like platforms.

Manishearth
You can call into Rust directly from C++ (with a header file).

But yeah, the reverse requires a C layer. rust-bindgen has experimental C++ support which we use for spidermonkey but it isn't perfect.

sitkack
> You can call into Rust directly from C++ (with a header file).

Can you tell me more about this?

steveklabnik
This is C and I tossed it together VERY quickly but

        $ cat hello.rs
        #[no_mangle]
        pub extern fn plus_one(x: isize) -> isize {
            x + 1
        }
        $ cat hello.c
        #include<stdio.h>

        extern int plus_one(int);

        int main() {
                int result = plus_one(5);

                printf("result is %d\n", result);

                return 0;
        }
        $ rustc hello.rs --crate-type=dylib
        $ gcc hello.c -lhello -L .
        $ LD_LIBRARY_PATH=. ./a.out
        result is 6
sitkack
I get the calling into Rust from C via no_mangle + extern. I was looking for the header only C++ to Rust path.
steveklabnik
Hm, I might have misunderstood either you or the OP, then. A C++ header would include the same extern declaration, though it would mark it with the C ABI as well.
Manishearth
It's the same way you call into C from C++. When Rust has a no_mangle extern C function to the universe it's just a C function. Your C++ header just needs to mark the fn as extern C and you're done, you can call it as you would call any other C/++ function.
sitkack
Oh, I thought there was a magical way to call from C++ into Rust using only a C++ header w/o no_mangle/extern.
pjmlp
C never had one standard ABI, not one that I can read in ANSI C document.

What happens is that C ABI == OS ABI, when the OS is written in C. This is not the case in the mainframe OSes that are still alive, for example.

So people have come to expect C ABI as being some kind of standard.

On an OS written in pure C++, the OS vendor C++ compiler would be the ABI.

Having said this, there are efforts to partially standardize the C++ ABI:

https://isocpp.org/blog/2014/05/n4028

Also many vendors use the Intel's C++ Itanium ABI as reference.

gpderetta
Note that the standardization effort is not what most people expect. It really is just a call for:

a) each platform to document its C++ABI. b) each platform to offer a ABI stable variant of the standard library as an option.

Both points are really already the norm and the default on many platforms. For example GCC on most OSs follows the documented Itanium ABI while libstdc++ has been ABI stable for a long time at least on Linux.

The notable exception is windows and MSVC. While the C ABI is documented, I believe that C++ ABI is pretty much "whatever MSVC does" and had to be reverse enginereed. Additionally MSVC reservers the right to break its library ABI at every major release (and in fact it does).

pjmlp
Sure, hence why I said partially.

However being mainly a .NET/JVM developer nowadays, I just follow C++ standardization on the sidelines.

Thanks for correction.

voiper1
>If all you've got is a big ball of mud, then your first step is to work on the modularization of your codebase (which, IMO, has a good chance of increasing your code quality regardless of whether you eventually decide to introduce any Rust).

I wanted to up-vote that bit.

MichaelGG
Since Rust and C can agree on ABI and memory layout issues, you can move the code over function-by-function if you were so inclined, right? Declare the structs in the headers and auto-gen the Rust versions (is there a tool for the inverse?).
comex
You can, but idiomatic Rust code looks pretty different from idiomatic C code - to give a concrete example,

    int get_a_string(char **out) // returns error code
could be translated literally as

    fn get_a_string(out: *mut *mut c_char) -> c_int
but much preferable would be

    fn get_a_string() -> Result<String, Errcode>
[where Result and String are standard library types; Errcode would be a custom enum.]

I suppose you could go from the first to the second incrementally, then refactor to the third. But I'm not sure it'd work well.

randommodnar
Is there a solution yet in Rust to this problem of, monadic-ish constructs like Result and Option, but no nice way to chain them together without hideous nesting, like Haskell's "do" or Scala's "for"?
steveklabnik
We don't have HKT and therefore we can't have real do notation. The mdo crate provides a duck-typed macro.

.and_then calls themselves aren't too bad, with the right whitespace.

comex
In the special case of Result, the new ? operator is going to subsume try! and offer more flexibility:

https://github.com/rust-lang/rfcs/pull/243 (note that what was actually accepted differs from the text of the RFC, you need to scroll to the bottom)

As steveklabnik says, there's nothing resembling generalized monadic do notation for now.

kibwen
This presumes that functions are well-defined boundaries in your C codebase, which may not be true if one is leaning heavily on global state.
CoconutPilot
Is there an anti-pattern for this kind of thing? Its a two line bug report suggesting years of development effort. There is a huge multiplication factor between the time invested by the bug reporter and the time required to do what he asks.
alexnewman
Only if your goal is to doom the existing tor project. Lots of great research projects start this way. Often times it influences the main project or merges.
erlend_sh
The discussion is 10 months old and never went anywhere. What makes this relevant now?
roywiggins
It would be a bit embarrassing to rewrite in Rust and then have the network penetrated because they screwed up the crypto during the rewrite...
[dead] WizardlySquid
Rewrite %s in whatever the newest hipster language is.