'new' class method

[Yigal Chripun]

KennyTM~ wrote:
> Yigal Chripun wrote:
>> 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)..
> 
> Then Allocator must be known in compile time? Though also in STL.
> 
>>
>> 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.
> 
> Yes. Although the problem right now is syntactical. :(
> 
>>
>> other ideas how to approach this?
>>
> 
> Use the semicolon:
> 
>   Class.new(parameters; allocator params);

if there's an allocator object, you don't need the above. just pass the
extra params to the alloc object itself and not the C-tor.
i.e: Class.new(params, Allocator(params));

extended example:

SharedMemoryAllocator shmAlloc(params);
auto a = ClassA.new(params, shmAlloc);
auto b = ClassB.new(params, shmAlloc);
auto c = StructA.new(params, shmAlloc);
auto d = ClassC.new(params); // default Class Allocator (on heap)
auto e = Struct.new(params); // default Struct Allocator (on stack)
auto d = ClassC.new(params, StackAlloc); // on stack
auto e = Struct.new(params, GCAlloc); // on heap

something like that will require the compiler/runtime to recognize the
allocator interface as special I think...