638
edits
GC API: Difference between revisions
→Allocation: update after today's irc meeting
m (next meeting) |
(→Allocation: update after today's irc meeting) |
||
| Line 51: | Line 51: | ||
} '''GCAllocFlags'''; | } '''GCAllocFlags'''; | ||
The ''flags'' parameter to the allocation functions is a bitwise OR of <code>GCAllocFlags</code> constants. Currently we only have one: <code>GC_HAS_FINALIZER</code> indicates that the allocation starts with a C++ object of a type that has a virtual destructor. The GC will call the destructor at some point after the object becomes unreachable and before its memory is reused or the heap is destroyed. | The ''flags'' parameter to the allocation functions is a bitwise OR of <code>GCAllocFlags</code> constants. Currently we only have one: <code>GC_HAS_FINALIZER</code> indicates that the allocation starts with a C++ object of a type that has a virtual destructor. The GC will call the destructor at some point after the object becomes unreachable and before its memory is reused or the heap is destroyed. This is the only API for per-object finalizers. | ||
void * '''gc_alloc_no_pointers'''( | void * '''gc_alloc_no_pointers'''( | ||
| Line 86: | Line 86: | ||
Allocate and zero out memory for an array. The layout of the array consists of an optional header described by ''headerLayout'', followed by ''count'' array elements, each described by ''elementLayout''. Returns a pointer to the beginning of the allocation (the header). | Allocate and zero out memory for an array. The layout of the array consists of an optional header described by ''headerLayout'', followed by ''count'' array elements, each described by ''elementLayout''. Returns a pointer to the beginning of the allocation (the header). | ||
'''Open issue:''' | '''Open issue:''' Weak references. (At the moment I'm leaning toward just providing an end-of-mark-phase GC callback and a IsAboutToBeCollected API and letting users build weakrefs on top of this.) | ||
== Explicit deallocation == | == Explicit deallocation == | ||