On Sun, Jun 30, 2013 at 10:22 AM, james <[email protected]> wrote: > 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.
There's no way to dynamically allocate space on the stack in Rust. If it was possible, it would require unsafe code to obtain the arbitrary pointer and more unsafe code to pass it into functions requiring that object. All of those functions would have to be explicitly designed for this pattern and marked as unsafe. > 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. I don't think it's possible. > 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 could offer alternate strategies for compiling generics, we aren't restricted to specializing them in every case forever. Keep in mind iterator adaptors are tiny functions and that inlining them is always desired, for every one that's currently done. If you do write a large function using iterators, you can hoist out the parts that don't require generic code as a workaround. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
