'new' class method

[Yigal Chripun]

KennyTM~ wrote:
> Yigal Chripun wrote:
>> KennyTM~ wrote:
>>> KennyTM~ wrote:
>>>> Bill Baxter wrote:
>>>>> On Sat, Oct 25, 2008 at 2:04 AM, KennyTM~ <kennytm at gmail.com> wrote:
>>>>>
>>>>>>>  auto a = Class();  // heap   (default)
>>>>>>>  auto a = Struct(); // stack   (default)
>>>>>>>
>>>>>>>  auto a = Class.new(stack)(); // stack
>>>>>>>  auto a = Struct.new(stack)(); // stack
>>>>>>>
>>>>>>>  auto a = Class.new(heap)(); // heap
>>>>>>>  auto a = Struct.new(heap)(); // heap
>>>>>>>
>>>>>>>   void *addr;
>>>>>>>   auto a = Class.new(addr)(); // placement
>>>>>>>   auto a = Struct.new(addr)(); // placement
>>>>>>>
>>>>>> I strongly *oppose* using stack and heap as keywords because there
>>>>>> are also
>>>>>> (partly irrelevant) data structures called stack and heap, even
>>>>>> though
>>>>>> according to the guideline these class/structs should be named Stack
>>>>>> and
>>>>>> Heap.
>>>>> Right, that's why both Benji and I proposed making them *context*
>>>>> keywords.  Just like "Windows" is a keyword only in the context of
>>>>> extern( ).  This would make heap and stack keywords only in the
>>>>> context of new(  ).
>>>>>
>>>> I see. But with the your new(...) syntax this can't be done because it
>>>> is ambiguous with
>>>>
>>>>   void* stack = allocate();
>>>>   auto C = Class.new(stack)();
>>>>
>>>> The placement new syntax should use some other syntax.
>>>>
>>> or do it like this:
>>>
>>>    auto C = Class.new(placement, addr, etc)();
>>> //--------------------^ use this to specify it is a placement new.
>>
>> 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.

I did mean the constructor arguments. The syntax itself is less
important here, I was more talking about the concept of Allocators.
like the ones in STL, for example.

regarding the syntax:
a few possibilities that come to mind:

a) new!(Allocator)(args)..

b) Allocator is just a regular parameter which you can add to your args
list. now the c-tor need some machinery to handle the allocator.
I'd say something like:
a c-tor does two things, gets memory and puts stuff into that memory.
so the first thing a c-tor does is automatically calls a default
Allocator for the type to get memory, *unless* you call one explicitly
yourself. it's similar to the way a c-tor has an implicit super() call
if you don't call that yourself only this probably will need additional
machinery to work.

other ideas how to approach this?