Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
"Rust vs. C++: Fine-grained Performance"
94 views
Skip to first unread message
Lynn McGuire
Feb 8, 2016, 4:52:07 PM2/8/16
to
"Rust vs. C++: Fine-grained Performance"
cantrip.org/rust-vs-c++.html
Modules, modules, modules!
And Go is coming up fast according to my son.
Lynn
cantrip.org/rust-vs-c++.html
Modules, modules, modules!
And Go is coming up fast according to my son.
Lynn
SG
Feb 9, 2016, 9:42:26 AM2/9/16
to
Am Montag, 8. Februar 2016 22:52:07 UTC+1 schrieb Lynn McGuire:
> "Rust vs. C++: Fine-grained Performance"
> cantrip.org/rust-vs-c++.html
>
> Modules, modules, modules!
Rust also has constrained generics and does the kind of modular type
> "Rust vs. C++: Fine-grained Performance"
> cantrip.org/rust-vs-c++.html
>
> Modules, modules, modules!
checking Doug Gregor promised to us for C++ in the 2009 Concepts
proposal. "Concepts lite" does not do that, by the way.
There is a lot to like about Rust. The core language as well as the
standard library is well-thought-out. The tools around Rust are nice
(the package and dependency manager cargo, rustdoc). Unit-Testing
is easy and painless. The process of adding to the language is open
and documented. I'm excited to see where this is all going.
Apart from the obviously small set of Rust libraries people have
developed so far due to the language being rather young (small
compared to what the C and C++ ecosystems have to offer), there are
only a handful of things I whish would improve, for example, "impl
specialization" [0] and "type-level integers" [1]. Oh, and the
compiler could be faster, too. :)
> And Go is coming up fast according to my son.
support for generic programming. I also don't like the C-style error
handling [2]. Being able to return multiple things from functions is
nice but not much of an improvement if you are still supposed to
manually check the error value and can forget to do so. It seems
pairs are the wrong choice for a return type of a function that can
fail to do its job. This is my conclusion after being exposed to
programming languages that support sum types and pattern matching.
[0] https://github.com/rust-lang/rfcs/issues/1038
[1] https://github.com/rust-lang/rfcs/pull/1210/
[2] https://blog.golang.org/error-handling-and-go
Cheers!
sg
Juha Nieminen
Feb 9, 2016, 6:54:39 PM2/9/16
to
SG <s.ges...@gmail.com> wrote:
> There is a lot to like about Rust. The core language as well as the
> standard library is well-thought-out. The tools around Rust are nice
> (the package and dependency manager cargo, rustdoc). Unit-Testing
> is easy and painless. The process of adding to the language is open
> and documented. I'm excited to see where this is all going.
C++ has one pragmatic advantage that most non-compatible languages
> There is a lot to like about Rust. The core language as well as the
> standard library is well-thought-out. The tools around Rust are nice
> (the package and dependency manager cargo, rustdoc). Unit-Testing
> is easy and painless. The process of adding to the language is open
> and documented. I'm excited to see where this is all going.
do not: If I need a library for some specific task, there are really
high chances that there will be a decent C (sometimes even C++) library
out there that does exactly that. For almost any problem you might
imagine.
I have no idea if C libraries can be used in Rust, but if they can't,
then that's a big point against it. Sure, its library of libraries
(hah!) may be constantly increasing, but it's doubtful it will be
reaching the vastness of the C/C++ libraries out there.
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Paavo Helde
Feb 10, 2016, 5:27:36 AM2/10/16
to
On 10.02.2016 1:54, Juha Nieminen wrote:
A side note: in my experience it is often easier to use C libraries than
C++, because of all the ABI and language incompatibilities. Even if the
library is written itself in C++, it might be useful to create a C
interface on top of that.
The C interface could be wrapped in a thin C++ header-only wrapper which
creates or restores RAII and maybe automates some parameter conversions.
There are exceptions like Boost or TinyXML which are either extensively
tested and maintained or just so simple that they compile with
everything and cause no headaches. But even with Boost there are
occasional hiccups when new compiler versions come out.
> I have no idea if C libraries can be used in Rust,
A quick google search says Rust can use C libraries, but not C++. This
just adds another argument for creating C interfaces for C++ libraries.
Cheers
Paavo
> SG <s.ges...@gmail.com> wrote:
>
> C++ has one pragmatic advantage that most non-compatible languages
> do not: If I need a library for some specific task, there are really
> high chances that there will be a decent C (sometimes even C++) library
> out there that does exactly that. For almost any problem you might
> imagine.
+1
>
> C++ has one pragmatic advantage that most non-compatible languages
> do not: If I need a library for some specific task, there are really
> high chances that there will be a decent C (sometimes even C++) library
> out there that does exactly that. For almost any problem you might
> imagine.
A side note: in my experience it is often easier to use C libraries than
C++, because of all the ABI and language incompatibilities. Even if the
library is written itself in C++, it might be useful to create a C
interface on top of that.
The C interface could be wrapped in a thin C++ header-only wrapper which
creates or restores RAII and maybe automates some parameter conversions.
There are exceptions like Boost or TinyXML which are either extensively
tested and maintained or just so simple that they compile with
everything and cause no headaches. But even with Boost there are
occasional hiccups when new compiler versions come out.
> I have no idea if C libraries can be used in Rust,
just adds another argument for creating C interfaces for C++ libraries.
Cheers
Paavo
SG
Feb 10, 2016, 7:24:39 AM2/10/16
to
Am Mittwoch, 10. Februar 2016 00:54:39 UTC+1 schrieb Juha Nieminen:
mentioned it in the paragraph that followed the one you quoted.
> I have no idea if C libraries can be used in Rust, but if they can't,
> then that's a big point against it.
Many Rust libraries you can find are actually bindings to other C
libraries (SDL2, PortAudio, lower level async I/O, ...). Rust
supports calling C functions and Rust can expose a function with C
linkage in order to allow C code to call Rust code. But all this
happens outside of the safe subset of Rust. So, the strategy for
using some C library from Rust is to add a Rust layer on top that
exposes a safe and Rusty interface. For example, if some C library
offers an interface like this:
struct opaque_context_s;
typedef struct opaque_context_s opaque_context_t;
// might return NULL in case something went wrong
opaque_context_t* create();
void destroy(opaque_context_t*);
// warning: the returned char pointer is only valid
// until you destroy the context!!!
const char* get_name(opaque_context_t*);
This is usually wrapped in Rust RAII-style like this:
// private declarations for the C interface of the library...
enum Opaque {}
extern fn create() -> *mut Opaque;
extern fn destroy(handle: *mut Opaque);
extern fn get_name(handle: *mut Opaque) -> *const ffi::c_char;
// public Rust interface layer...
pub struct Context { // our RAII wrapper
handle: *mut Opaque,
}
impl Drop for Context { // "destructor"
fn drop(&mut self) {
unsafe { destroy(self.handle); }
}
}
impl Context {
pub fn new() -> Result<Self,()> {
let raw = unsafe { create() };
if raw.is_null() { return Err(()); }
Ok(Context { handle: raw })
}
pub fn get_name(&self) -> &ffi::CStr {
unsafe {
let raw = get_name(self.handle);
ffi::CStr::from_ptr(raw)
}
}
}
You could write something similar in C++. After all, resource
management in Rust is heavily inspired by C++. But an important
difference here is that the warning you saw in the documentation of
the C interface is actually encoded in the Rust signatures in a way
that the compiler understands them and checks for. The easy way
would have been to immediately convert the char* to an owned string
and return it by value from the get_name method to avoid lifetime
issues. But in Rust we can do better. The full return type of
get_name is actually "&'x CStr", a reference that refers to the C
string allocated by the C library constrained by a some lifetime
parameter "x" that in this case is implicitly tied to the lifetime of
the *self object by one of the lifetime elision rules of the core
language. The Rust compiler would not allow us to hold on to this
&CStr after the RAII wrapper ceases to exist. The following code
snippet that contains such a use-after-free error would not compile:
fn foo() -> Result<&ffi::CStr,()> {
let short_lived = try!(Context::new());
return short_lived.get_name();
}
This way, we provided a Rust interface that does not allow the user
create use-after-free errors while avoiding unnecessary heap
allocations for temporary string objects.
Magic! :)
sg
> SG wrote:
> > There is a lot to like about Rust. The core language as well as the
> > standard library is well-thought-out. The tools around Rust are nice
> > (the package and dependency manager cargo, rustdoc). Unit-Testing
> > is easy and painless. The process of adding to the language is open
> > and documented. I'm excited to see where this is all going.
>
> C++ has one pragmatic advantage that most non-compatible languages
> do not: If I need a library for some specific task, there are really
> high chances that there will be a decent C (sometimes even C++) library
> out there that does exactly that. For almost any problem you might
> imagine.
Yes. This is obviously the case for every young language. I
> > There is a lot to like about Rust. The core language as well as the
> > standard library is well-thought-out. The tools around Rust are nice
> > (the package and dependency manager cargo, rustdoc). Unit-Testing
> > is easy and painless. The process of adding to the language is open
> > and documented. I'm excited to see where this is all going.
>
> C++ has one pragmatic advantage that most non-compatible languages
> do not: If I need a library for some specific task, there are really
> high chances that there will be a decent C (sometimes even C++) library
> out there that does exactly that. For almost any problem you might
> imagine.
mentioned it in the paragraph that followed the one you quoted.
> I have no idea if C libraries can be used in Rust, but if they can't,
> then that's a big point against it.
libraries (SDL2, PortAudio, lower level async I/O, ...). Rust
supports calling C functions and Rust can expose a function with C
linkage in order to allow C code to call Rust code. But all this
happens outside of the safe subset of Rust. So, the strategy for
using some C library from Rust is to add a Rust layer on top that
exposes a safe and Rusty interface. For example, if some C library
offers an interface like this:
struct opaque_context_s;
typedef struct opaque_context_s opaque_context_t;
// might return NULL in case something went wrong
opaque_context_t* create();
void destroy(opaque_context_t*);
// warning: the returned char pointer is only valid
// until you destroy the context!!!
const char* get_name(opaque_context_t*);
This is usually wrapped in Rust RAII-style like this:
// private declarations for the C interface of the library...
enum Opaque {}
extern fn create() -> *mut Opaque;
extern fn destroy(handle: *mut Opaque);
extern fn get_name(handle: *mut Opaque) -> *const ffi::c_char;
// public Rust interface layer...
pub struct Context { // our RAII wrapper
handle: *mut Opaque,
}
impl Drop for Context { // "destructor"
fn drop(&mut self) {
unsafe { destroy(self.handle); }
}
}
impl Context {
pub fn new() -> Result<Self,()> {
let raw = unsafe { create() };
if raw.is_null() { return Err(()); }
Ok(Context { handle: raw })
}
pub fn get_name(&self) -> &ffi::CStr {
unsafe {
let raw = get_name(self.handle);
ffi::CStr::from_ptr(raw)
}
}
}
You could write something similar in C++. After all, resource
management in Rust is heavily inspired by C++. But an important
difference here is that the warning you saw in the documentation of
the C interface is actually encoded in the Rust signatures in a way
that the compiler understands them and checks for. The easy way
would have been to immediately convert the char* to an owned string
and return it by value from the get_name method to avoid lifetime
issues. But in Rust we can do better. The full return type of
get_name is actually "&'x CStr", a reference that refers to the C
string allocated by the C library constrained by a some lifetime
parameter "x" that in this case is implicitly tied to the lifetime of
the *self object by one of the lifetime elision rules of the core
language. The Rust compiler would not allow us to hold on to this
&CStr after the RAII wrapper ceases to exist. The following code
snippet that contains such a use-after-free error would not compile:
fn foo() -> Result<&ffi::CStr,()> {
let short_lived = try!(Context::new());
return short_lived.get_name();
}
This way, we provided a Rust interface that does not allow the user
create use-after-free errors while avoiding unnecessary heap
allocations for temporary string objects.
Magic! :)
sg
woodb...@gmail.com
Feb 10, 2016, 6:00:45 PM2/10/16
to
On Wednesday, February 10, 2016 at 4:27:36 AM UTC-6, Paavo Helde wrote:
> On 10.02.2016 1:54, Juha Nieminen wrote:
> > SG <s.ges...@gmail.com> wrote:
> >
> > C++ has one pragmatic advantage that most non-compatible languages
> > do not: If I need a library for some specific task, there are really
> > high chances that there will be a decent C (sometimes even C++) library
> > out there that does exactly that. For almost any problem you might
> > imagine.
>
> +1
>
They also don't seem to have anticipated on line code generation.
> On 10.02.2016 1:54, Juha Nieminen wrote:
> > SG <s.ges...@gmail.com> wrote:
> >
> > C++ has one pragmatic advantage that most non-compatible languages
> > do not: If I need a library for some specific task, there are really
> > high chances that there will be a decent C (sometimes even C++) library
> > out there that does exactly that. For almost any problem you might
> > imagine.
>
> +1
>
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
0 new messages