On 29/06/2013 22:32, Daniel Micay wrote:
On Sat, Jun 29, 2013 at 5:29 PM, james<[email protected]> wrote:
>On 29/06/2013 18:39, Niko Matsakis wrote:
>
>if you were going to store the result on the caller's stack frame, the
>caller would have to know how much space to allocate! Conceivably one
>
>
>If you can have a function that returns an allocated iterator, can't you
>instead have
>a function that informs how big it would be, and a function that uses a
>passed in
>pointer from alloca?
We don't have alloca, but if we did, it would be less efficient than a
statically sized allocation since it would involve an extra stack size
check. A low-level, unsafe workaround like that isn't needed when you
can just have a function return an iterator of a specific type.
Well, if the caller knows the type of the returned object and it is
returned by value - yes.
But I thought the discussion had strayed to considering a case where the
type is hidden
inside the iterated-over object, so the caller using the pattern does
not know how to
allocate space for it and receive such an object by value. I was trying
to suggest that
it is not necessary for the caller to know much about the iterator
object to avoid a
heap allocation - it has to ask the size, and it has to then allocate
and pass some raw
storage on its stack. And I guess it has to ask for a function to call
on the raw store
when it has finished with it.
I'm not claiming that this is more efficient that a return by value,
just that it may be
possible to avoid a heap allocation even in the case where the call site
only sees an
abstract iterator interface, and does not know any details.
This is very much similar to tradeoffs in C++ between using inheritance
and interfaces
vs templates, and my experience has been that moving to templates has in
some
cases swapped a small runtime overhead for major problems with
compilation speed
and emitted code size - and the latter has caused runtime performance
issues all of
its own.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
