[Issue 4681] Appender access violation

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Aug 26 06:30:10 PDT 2010


http://d.puremagic.com/issues/show_bug.cgi?id=4681



--- Comment #14 from Steven Schveighoffer <schveiguy at yahoo.com> 2010-08-26 06:30:03 PDT ---
(In reply to comment #13)
> (In reply to comment #12)
> > Why are runtime calls dirty?  I don't use any undocumented runtime functions...
> 
> Because they do more work than necessary and rely on more implementation
> details than necessary. Also, more bugs (oh hey look, we're posting in a bug
> report). I'm most worried about the assumptions of the array memory layout.

I'm not assuming anything about the memory layout.  GC.qalloc gives me a block
of data, and I'm using the data.  Its interface is well defined without any
hidden assumptions.

Besides, you are calling the same runtime functions, just using a different
interface.  I don't see how one is more "dirty" than the other, we are both
using well-documented runtime functions.

> 
> > Because the call to the runtime cannot be inlined, and is much slower than
> > simply dereferencing a pointer.  Appender is supposed to be as fast as possible
> > at appending.
> 
> My code only calls runtime functions when the capacity is exhausted. As long as
> there's enough capacity, not a single runtime function is called on appending.
> It's really similar to all the code that has been in Appender before, except
> less dirty.

Your code calls the lifetime runtime functions, which call the GC runtime
functions.  My code just calls the GC functions, skipping the lifetime
functions.  Like your code, mine only calls runtime functions on exhaustion.

BTW, the statement I was responding to asked why you can't just use runtime
functions to determine capacity, I interpreted that as you wishing to use the
runtime management of array memory for every append.  I hadn't read your code
yet.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list