OpenE2K/rust
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Further revisions suggested by nmatsakis (#2990).

Browse Source
This commit is contained in:
Lindsey Kuper 2012-07-22 19:19:30 -07:00
parent d9cbdf7865
commit 019a41bdb0
1 changed files with 8 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
doc/tutorial.md
View File

@ -1197,15 +1197,14 @@ Rust has three competing goals that inform its view of memory:
## How performance considerations influence the memory model ## How performance considerations influence the memory model
Many languages that offer the kinds of memory safety guarantees that Most languages that offer strong memory safety guarantees rely upon a
Rust does have a single allocation strategy: objects live on the heap, garbage-collected heap to manage all of the objects. This approach is
live for as long as they are needed, and are periodically straightforward both in concept and in implementation, but has
garbage-collected. This approach is straightforward both in concept significant costs. Languages that take this approach tend to
and in implementation, but has significant costs. Languages that take aggressively pursue ways to ameliorate allocation costs (think the
this approach tend to aggressively pursue ways to ameliorate Java Virtual Machine). Rust supports this strategy with _shared
allocation costs (think the Java Virtual Machine). Rust supports this boxes_: memory allocated on the heap that may be referred to (shared)
strategy with _shared boxes_: memory allocated on the heap that may be by multiple variables.
referred to (shared) by multiple variables.
By comparison, languages like C++ offer very precise control over By comparison, languages like C++ offer very precise control over
where objects are allocated. In particular, it is common to put them where objects are allocated. In particular, it is common to put them