Hello, Regarding type-erasure without stack-allocation I remember a question on StackOverflow on how to implement this.
In C++ this can be done using templates => template <typename T, size_t Size, size_t Alignment> class Pimpl; Pimpl will then declare raw storage (char [] in C++03, std::aligned_storage<Size, Alignment>::type in C++11), and then this space will be used by `T` (which was forward declared). An important (and maybe overlooked) aspect is that Size and Alignment are upper-bounds. Whilst to avoid wasting space it is better they be as close to the necessary value, equality is not necessary. And thus one could perfectly imagine a AgnosticIterator<RandomIterator, 16, 8> and it is up to the builder to create a type that fit... and maybe use dynamic allocation as a fallback if the iterator state cannot fit within the provided size. -- Matthieu. On Sun, Jun 30, 2013 at 4:22 PM, 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]> > <[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 > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
