'new' class method

[Bill Baxter]

On Sat, Oct 25, 2008 at 11:03 PM, KennyTM~ <kennytm at gmail.com> wrote:

>>>   auto C = Class.new(placement, addr, etc)();
>>> //--------------------^ use this to specify it is a placement new.

Yeh, I was thinking that was a possibility too, if  .new(heap,a)
.new(stack,a) and .new(a) weren't sufficiently distinct.
I was thinking to call it  .new(place,a), though.  But same idea.

>> maybe just add the concept of allocators.
>> auto C1 = Class.new(parameters/*, Allocator = GC.DefaultAllocator */);
>> auto C2 = Class.new(parameters, HeapAllocator); // on heap
>> auto C3 = Class.new(parameters, StackAllocator); // on stack
>> auto C4 = Class.new(parameters, MyPlacementNewAllocator);
>> etc..
>> initial Allocator hierarchy could be part of the run-time, and could be
>> user extended to allow for placement new.
>>
>
> This can't work because parameters (I bet you mean constructor arguments
> here) can be variadic.

You could fix that by putting the allocator first, or attach params to
the allocator

    auto C4 = Class.new(MyPlacementNewAllocator(parameters))

The bigger concern to me is that StackAllocator can't be just a
regular allocator.  The compiler would have to recognize that
StackAllocator was being used and reserve the appropriate space on the
stack, and then pass that stack address to the StackAllocator somehow.
 It's not impossible but it sounds messy from the implementation
perspective.  And I find it kind of jarring that the three modes look
similar, but one is actually invoking deep compiler magic while the
other two are just regular Joes.

--bb