[Issue 11138] "real" appender missing

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Oct 20 03:26:07 PDT 2013


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


Dmitry Olshansky <dmitry.olsh at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmitry.olsh at gmail.com


--- Comment #4 from Dmitry Olshansky <dmitry.olsh at gmail.com> 2013-10-20 03:26:03 PDT ---
(In reply to comment #1)
> (In reply to comment #0)
> > 3. Needless restriction on element type.
> >     One may want to create and array of uncopyable type which non-"real"
> > appender can't do by definition.
> 
> Appender supports immutable construction (mostly bug free, AFAIK). I don't
> think a "real" appender would do any better than appender could anyways, so
> this is a non-argument (IMO).
> 

Construct in place. See also C++11 emplace_back and friends. Even these guys
see the benefit.

> > 2. Performance.
> >     It will cause calls of postblits and then destructors on collection of copy
> > array.
> 
> Technically, the destructors don't need to be called, since the GC will leak
> them anyways :/ See below about "postblits"

Who told you that a long-standing bug allows us to basically do even worse job
then we have to ? ;)

> > Lets call "real" an appender which will create the one and only array, i.e. it
> > will not randomly create a copy of array on appending. Such copy is bad as:
> > 1. Almost no use.
> >     In 99% appender is used as "real" appender and the copy is not needed.
> 
> I've thought about this before. The *only* case this would really change
> anything, is on structs that have an elaborate CC. Arguably, these things have
> no business being in a GC managed array, since it never finalizes its elements
> (and arguably, if you have a CC, you have a destructor). If we ever get a
> finalizing GC, then things will be different.
> 
> One "workaround" I've though about is that when the type has a CC, Appender
> could carry an extra "ownsArray" boolean. If appender must relocate its array,
> and "owns" the array, then postblit is not necessary. In the future, if the GC
> is finalizing, it may also have to re-initialize to T.init, if there is an
> elaborate destructor.

Sadly Appender leaks refernces to its internal array so it's can own the data
at all.

> > Obviously, "real" appender is uncopyable
> 
> Appender having ref semantics, there would be absolutely no problem "copying"
> it (read: pass by value).

IMHO it could just be uncopyable type and RefCounted!T should solve the issue
of passing it as reference anywhere. 

> > and don't give safe access to its
> > array until it finished.
> 
> I can see the motivation behind this "real" appender. Another (dis)advantage it
> has is that it wouldn't be initialize-able from an existing array. This means
> it would have 100% ownership of its internals, but on the other hand, it also
> means, it also means it can't extend an exiting array :/

You miss a big use case. Frankly patching Appender on top of an array is a
minor thing that buys us a tiny bit over assumeSafeAppend.

Doing a lot of reallocations in the process of building and not owning data is
what makes Appender very poor at constructing ... array-like containers.

> So, "at the end of the day", I'm not really sure a "real" appender would pull
> its weight compared to the standard appender (IMO).

Then call it a Builder! Such a builder has a chance at good API design unlike
the current abomination. In particular it could accumulate data in chunks and
never reallocate until the very end. Secondly while assembling the final
array/container it may move data freely both supporting non-copyable stuff
_and_ being more efficient.

-- 
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