'new' class method

[KennyTM~]

Yigal Chripun wrote:
> 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...
> 
> 

What if the constructor may take the allocator object as its argument?

class X {
    string t;
    this(string x, Allocator alc = Allocator.init) {
       t = x ~ alc.toString();   // why not?
    }
}

SharedMemoryAllocator shmAlloc(alloc_params);
auto x = X.new("abc", shmAlloc);   // what I'm calling?

The semi-colon version disambiguates this situation.