Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust for C++ programmers – part 4: unique pointers

featherweightmusings.blogspot.com

Post reply on HN
Print view View original

41–50 of 99 posts

Re: Rust for C++ programmers – part 4: unique pointers

#41

Post by NAFV_P »

captainmuon wrote: post #21

Rust gives me the same feeling I had when learning C. I started with BASIC, then learned Java and a bit of Pascal, Perl, etc., but C was my first language with pointers. Now it seems silly, but understanding pointers was a huge step to me. There's a before and an after. Getting used to owned/transferable pointers seems to involve a similar step, although it's probably easier this time since I understand what they do.…

> Rust gives me the same feeling I had when learning C. I started with BASIC, then learned Java and a bit of Pascal, Perl, etc., but C was my first language with pointers. Now it seems silly, but understanding pointers was a huge step to me.

You learned programming the right way round, unlike myself. One of the current problems with the web is that any old noob can learn any old language, so rather than following good advice and learning Python, I hacked C. One of the most interesting things about C is the more proficient you become, the more you use pointer to pointer to pointer of type array of pointer to function that returns a pointer to pointer of type array of pointer to function that returns pointer to void.

Proper high level languages just go straight over my head, they're way too complicated.

Re: Rust for C++ programmers – part 4: unique pointers

#42

Post by masklinn »

berkut wrote: post #38
masklinn wrote: post #33

Earlier quoted context omitted.

> How do you do ASM in Rust? There's an asm! macro: http://static.rust-lang.org/doc/0.10/guide-unsafe.html#inlin... > Can you align memory in rust? I think that's an open problem for now, e.g. https://github.com/mozilla/rust/issues/4578

Aligning memory is pretty important for high-performance apps using SSE/AVX (archs after SB don't need alignment any more, but still benefit from it) - and generally anyway - cacheline alignement, etc, and while it's often possible to force structs / classes to be aligned by padding them, this doesn't always work. Does Rust allow using memory allocated by specific external allocators? i.e. libnuma or something?

> Aligning memory is pretty important for high-performance apps using SSE/AVX

Er… yes? Did I say it was unimportant anywhere? (also please note that I'm not a Rust developer)

> Does Rust allow using memory allocated by specific external allocators? i.e. libnuma or something?

I'm not quite sure what you're asking

* if you're asking if it's possible to use arbitrary memory returned by a third party? Then yes.

* if you're asking whether user-defined allocators or boxes are supported and you can ask the runtime to put its stuff in memory you get from e.g. a bundled jemalloc, then that's planned but not in I believe: https://github.com/mozilla/rust/issues/12038

Re: Rust for C++ programmers – part 4: unique pointers

#43

Post by berkut »

masklinn wrote: post #42
berkut wrote: post #38

Earlier quoted context omitted.

Aligning memory is pretty important for high-performance apps using SSE/AVX (archs after SB don't need alignment any more, but still benefit from it) - and generally anyway - cacheline alignement, etc, and while it's often possible to force structs / classes to be aligned by padding them, this doesn't always work. Does Rust allow using memory allocated by specific external allocators? i.e. libnuma or something?

> Aligning memory is pretty important for high-performance apps using SSE/AVX Er… yes? Did I say it was unimportant anywhere? (also please note that I'm not a Rust developer) > Does Rust allow using memory allocated by specific external allocators? i.e. libnuma or something? I'm not quite sure what you're asking * if you're asking if it's possible to use arbitrary memory returned by a third party? Then yes. * if you'…

> Er… yes? Did I say it was unimportant anywhere?

No, but that link seemed to indicate it wasn't being planned for the first release and pcwalton seems to think it's possible to get Rust programs to run as fast as C++ programs in most cases.

Re: Rust for C++ programmers – part 4: unique pointers

#44

Post by rcxdude »

stewbrew wrote: post #35

I recently wondered whether it's possible to compile rust into a dll/so or whether there is a way to call rust from other languages (e.g. C, R, or ruby). All I found is that this isn't (easily?) possible because of rust's runtime. Is this true? If so, will it be possible to call rust from, e.g., C code? I'd like to have an alternative to c/c++ for writing native extensions for interpreted languages.

It's on the roadmap: there's plans to split the standard library into parts which require the runtime and parts which don't (as well as into parts which don't require malloc). As it stands you can write them, but you need to avoid parts of the standard library.

Re: Rust for C++ programmers – part 4: unique pointers

#45

Post by coldtea »

From the blog:

>I have history with Firefox layout and graphics, and programming language theory and type systems (mostly of the OO, Featherweight flavour, thus the title of the blog).

Hmm, what are "type systems" of "featherweight flavour"? Anything real or some inside joke? Or perhaps an elaborate way to say "not that complicated"?

(Google mostly returns references to the same blog)

Re: Rust for C++ programmers – part 4: unique pointers

#46

Post by coldtea »

bambam12897 wrote: post #8

I've been working C++ professionally for a couple of years and honestly I'm a huge fan - So I was excited to read about an alternative. After reading your 5 posts, I get the impression that RUST is mostly mildly useful syntactic sugar on top of C++. Here is my feedback: 1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. This seems like the main sell…

>1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. This seems like the main selling point for RUST.

No, the main selling point is memory management with guarantees for safety but full performance. You don't get that just with boost, it's mostly a GC.

>2 - I'm not a fan of the implicitness and I personally don't use 'auto' b/c it makes scanning code harder. I guess this is more of a personal preference.

Type inference removes redundant information.

>4 - the Rust switch statement don't fall through... This one was truly mind blowing. The one useful feature of switch statement got ripped it out!

Huh? The fall-through has been known to be a bug hazard and bad style for ages. And for what, to save a few lines with a not that clever trick? The only useful abuse of the Switch was Duff's device, and that's stretching it already.

Re: Rust for C++ programmers – part 4: unique pointers

#47

Post by steveklabnik »

berkut wrote: post #40
bad_user wrote: post #36

Earlier quoted context omitted.

> If memory management is a serious problem for the software you work on, I've never found the boost library lacking. As a developer that isn't working with C++, I'm finding memory management in C++ to be a nightmare and no amount of libraries can solve it. Say you receive a pointer from somewhere. Is the referenced value allocated on the stack or on the heap? If allocated on the heap, do you need to free it yourself…

I've never had an issue with memory management in C / C++ (and I've had experience of writing C#/Java in enterprise applications, so I know what not having to do it is like). There is an overhead to having to think and plan for it, but in my experience of using it for things ranging from realtime systems through to high performance, multi-threaded image processing and rendering applications, at least if you're in con…

Of course, if it's good code, then you're good. The issue is getting good code in the first place. ;) That's where static analysis can help: compilers are tireless. Humans are faulty.

Memory management issues cause tons of security issues in C++ applications. In the recent Pwn2Own, all of the security vulnerabilities in Firefox would have not been possible had Firefox been implemented in Rust.

Re: Rust for C++ programmers – part 4: unique pointers

#48

Post by steveklabnik »

stewbrew wrote: post #35

I recently wondered whether it's possible to compile rust into a dll/so or whether there is a way to call rust from other languages (e.g. C, R, or ruby). All I found is that this isn't (easily?) possible because of rust's runtime. Is this true? If so, will it be possible to call rust from, e.g., C code? I'd like to have an alternative to c/c++ for writing native extensions for interpreted languages.

The third production deployment of Rust is a Ruby extension written in Rust. https://air.mozilla.org/sprocketnes-practical-systems-progra... (You'll have to scroll forward)

And technically, it's a Ruby extension written in C. But the C is very small, and is mostly written in Rust. This is because Ruby's cexts use so many C macros, it was easier to make a shim then try to port them all to Rust.

Re: Rust for C++ programmers – part 4: unique pointers

#49

Post by masklinn »

coldtea wrote: post #45

From the blog: > I have history with Firefox layout and graphics, and programming language theory and type systems (mostly of the OO, Featherweight flavour, thus the title of the blog). Hmm, what are "type systems" of "featherweight flavour"? Anything real or some inside joke? Or perhaps an elaborate way to say "not that complicated"? (Google mostly returns references to the same blog)

I'd expect something along the lines of:

> Several recent studies have introduced lightweight versions of Java: reduced languages in which complex features like threads and reflection are dropped to enable rigorous arguments about key properties such as type safety. We carry this process a step further, omitting almost all features of the full language (including interfaces and even assignment) to obtain a small calculus, Featherweight Java, for which rigorous proofs are not only possible but easy.

> Featherweight Java bears a similar relation to Java as the lambda-calculus does to languages such as ML and Haskell. It offers a similar computational "feel," providing classes, methods, fields, inheritance, and dynamic typecasts with a semantics closely following Java's. A proof of type safety for Featherweight Java thus illustrates many of the interesting features of a safety proof for the full language, while remaining pleasingly compact. The minimal syntax, typing rules, and operational semantics of Featherweight Java make it a handy tool for studying the consequences of extensions and variations.

You can see a few of his pubs on his website: http://www.ncameron.org/papers/index.html

Post reply on HN