On Monday, 9 July 2012 at 07:53:41 UTC, David Piepgrass wrote:
I don't know if this proposal went anywhere since 2010, but it
occurs to me that there is a hidden danger here. alloca will
allocate a sequence of separate temporaries. If the collection
is large, the stack will overflow, and the client might not
have a clue what happened.
Amazing. My post unleashed four pages of comments and not one of
them responded to my post :O
I think Mehrdad is right that an in/out range should have its own
name to distinguish it from an input range, but that doesn't
necessarily mean that the same interface can't be used for both.
I imagine a couple of advantages of:
T tmp;
for(T* front = r.getNext(ref tmp))
// do something with front
instead of:
for(; !r.empty; r.popFront())
// do something with r.front
- If the range uses late-binding, getNext() is faster because
you're only calling one function instead of 3. When I program in
C#, I am quite irritated enough that IEnumerator requires 2
interface calls to get each item. Late binding, of course, is
necessary across DLL boundaries and can help avoid code bloat.
- If an input-only range has to unpack its elements (e.g. bit
array => bool, or anything compressed), the range doesn't need to
unpack repeatedly every time 'front' is accessed, nor does it
need to reserve memory inside itself for a scratch area (you
don't want scratch areas in every range if your app keeps track
of thousands of ranges; plus, ranges tend to get passed by value,
right?).
That said, it may be unreasonable for the compiler to support the
necessary escape analysis (impossible in case you're importing
.di files)... and maybe the existing empty/popFront/front is too
well established to reconsider? (I am not familiar with the
status quo).
