Proposal: takeFront and takeBack
Jonathan M Davis
jmdavisProg at gmx.com
Wed Jul 4 01:45:32 PDT 2012
On Wednesday, July 04, 2012 10:37:41 Mehrdad wrote:
> On Wednesday, 4 July 2012 at 08:35:30 UTC, Dmitry Olshansky wrote:
> > On 04-Jul-12 12:29, Mehrdad wrote:
> >> On Wednesday, 4 July 2012 at 08:25:59 UTC, Roman D. Boiko
> >>
> >> wrote:
> >>> That would be almost perfect. But has drawbacks:
> >>>
> >>> * if element is big and may be not needed in all calls to
> >>> popFront
> >>> (when the user wants to ignore elements), there would be some
> >>> overhead;
> >>
> >> Could you give an example of such a range? Does such a
> >> heavyweight range
> >> come up in practice? (I'm assuming RVO would take care of not
> >> calling
> >> copy constructors and such.)
> >
> > UTF strings - calculating length of codepoint is cheaper then
> > actually decoding it and then throwing away.
>
> No, I think you misunderstood my question. I definitely know the
> use case for /that/.
> I was talking about an example of what I replied to, i.e. where
> Roman said the "element is big". dchars aren't big.
No, but if popFront on strings returned a dchar, popFront would be more
expensive, because it would have to actually decode the code point rather than
just find the next one.
As for elements being big, if you created a struct with dozens of fields, many
of which were structs themselves, you'd definitely be incurring extra cost
every time that an element was returned needlessly. Having really large
structs like that is probably rare in ranges though, precisely because copying
them would be expensive. They'd probably be made reference types instead. But
still, having popFront return an element when it doesn't need to does incur a
cost, regardless of the type returned, and since popFront is used for
iteration, it'll happen in a loop pretty much by definition, which will
increase that cost.
Having popFront return an element is a _bad_ idea IMHO. Ideally, it would be
possible to either get front separately from popping an element and to get it
when popping an element, rather than restricting it to one or the other.
Adding consumeFront would make it possible to have both in the cases where it
actually mattered.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list