[rust-dev] Newbie questions about memory management

Colin Fleming colin.mailinglist at gmail.com
Sun Dec 30 13:55:13 PST 2012

Having thought about this some more, it seems like the concept of lifetime
is closely related to the allocation strategy. Is the compiler clever
enough to return a type allocated in a different way depending on the
parameter I pass it? i.e. will the compiler generate different code in the
following cases:

static fn new(value: &lifetime/str) -> StringReader/&lifetime {
  StringReader { data: value, next: 0 }

// Get these from somewhere
let x = @"abc"
let y = ~"abc"

let on_the_stack = StringReader::new("abc")
let managed = StringReader::new(x)
let owned = StringReader::new(y)

I'm assuming not, since I assume that T, ~T and @T are distinct types,
although I guess the compiler could compile 3 specialisations, similar to
monomorphism. But I guess that the lifetime here is actually the
stack-bound lifetime of the local variables (x and y) and not of the data
that they point to - is this right? If so, this implies that the rvalue
trick only really lets you take borrowed pointers to stack-bound variables,
which seems a little limited.

On 31 December 2012 10:26, Lucian Branescu <lucian.branescu at gmail.com>wrote:

> Ah, good point. I guess it just seems I'd be likely to not figure out why
> a programme gets slower when I add a let.
>  On 30 Dec 2012 20:58, "Patrick Walton" <pwalton at mozilla.com> wrote:
>> On 12/30/12 12:56 PM, Lucian Branescu wrote:
>>> Would it be possible to have a more general mechanism for creating and
>>> relinquishing objects? The rvalue trick seems obscure and only
>>> situationally useful.
>> Broadly speaking, that's what "move" is for. Did you want something
>> beyond that?
>> Patrick
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20121231/bf26cadb/attachment-0001.html>

More information about the Rust-dev mailing list