On Tuesday, 24 September 2013 at 18:53:56 UTC, Bigsandwich wrote:
Hi,
I mostly just lurk around here, but occasionally I just can't
resist putting in my two cents. I really want to see D replace
C++ for AAA games (my industry) and allocators are really
critical to that. I think there's an elephant here that most
of the posts have been dancing around.
In C++ when you roll your own allocators (whether STL
allocators or some other interface) there is basically, only
one set of *semantics* to worry about - the classic C++/C
pattern of new/delete or malloc/free. This is actually much
more complicated in D where you have at least two different
semantics:
1) C++/C style
2) Tracing/Garbage Collection
3) Region allocators and other oddballs
Consequences:
1) These semantics aren't really interchangeable. If, for
instance, a library is implemented with one of them in mind, it
can only be replaced by an allocator with the same semantics.
2) Tracing/Garbage Collection are required for whatever the
default allocator is and replacement allocator must implement
those semantics.
3) Its only possible to change (2) by hacking the runtime so
that any language features that rely on the GC cause errors.
The design Andrei has presents seems to *allow* the creation of
allocators with all of these semantics, but it doesn't seem to
answer the following questions:
1) Can semantics be enforced?
2) Can allocators with different semantics be composed?
3) Can different semantics for the default allocator be
implemented?
4) If so, how can I reconcile that with libraries that expect
different default semantics? A use case that I foresee for
something like this would be banning the use of GC in low level
engine code, but allowing it in higher level gameplay code.
5) Are any of these questions even relevant for this part of
the design or will we have to wait for the rest of it to know
the answers?
Thanks.
I'd like to see these question answered. This is one of the most
insightful posts of the discussion.
